GONE PLAN 



so, 



Brain 

Goes Whoosh! 



Going to the Computer Game 
Developer's Conference is like 
having your brain ripped from 
your skull, spun up to 90% of 
the speed of light, and fired into 
a reaction chamber filled with 
2,000 other brains moving at 
relativistic speeds. It's just as 
hard recreating theCGDC from business 
cards, press releases, and scrawled notes as 
it is seeing the signature of a Top quark in 
the spirals and parabolas of a reaction 
chamber photograph. 

Above any other impression, the 
overwhelming support for Game Developer 
from the community was both gratifying 
and humbling. To have so many people 
known to us only from their credits on 
shrinkwrap games come up and tell us that 
they read the magazine was amazing 
enough, but when they continued with 
specific comments about this column or 
that feature, I realized that our magazine's 
editorial staff isn't what's on the masthead, 
it's 20,000 strong. 

Despite the overload of informa- 
tion that makes it impossible to say 
what the story of the show was, I think 
there were three candidates: sound, 3D , 
and W indows. 

The sound story was a howl of rage 
against FM synthesis and its gaming syn- 
onym "SoundBlaster compatible." To 
many at the C G D C , the chirpy voice of an 
FM card through the molded plastic 
speakers bundled with a $60 card repre- 
sents the jackboot of tyranny on the throat 
of the gaming public. 

Although "rendered on the fly" 
sounds like what happens when an acceler- 
ated brain hits a screen door, it's also 
where the action is in terms of software. 
Although demos that don't have to bother 
with little things like gameplay always 
achieve higher frame rates, vendor after 
vendor was showing convincing evidence 
that the bar's been raised (or extruded) for 



popular graphics. 

But why fight it? The truly amazing 
thing is that all of this— the sound work, 
the three-dimensional graphics with 
incredible frame rates, the hottest con- 
tent—was running under a single platform. 
Windows. You heard me right, bunkies. 
M icrosoft has decided it wants the home 
market and will do what it takes to make 
the successor to W indows 95 (W indows 
95++?) the number one game platform. 

L ike anyone in the press, I 'm used to 
getting a lot of opinions about major 
M icrosoft initiatives. You expect some 
people to love it on technical merit, some 
people to hate it on technical merit, and a 
lot of people to hate it on the general prin- 
ciple that M icrosoft's a big, successful 
company and therefore is evil. But no mat- 
ter who I talked to about the M icrosoft 
Game SDK, with its four A Pis for graph- 
ics, input, network connection, and sound, 
it was a love story. 

N ot one to be swayed by public sen- 
timent, I put on my sunglasses with the 
special Anti-Hypnosis coating and met 
with M icrosoft's G ame SD K advance 
team. W hat can I say? T hey ripped off the 
glasses and made me stare at a screen with 
three objects composed of approximately 
8,000 G ouraud- shaded polygons rotating 
at dozens of frames per second. T hen they 
made me watch other displays with alpha 
channels, specular highlights, and smooth 
panning. They overlayed three-dimen- 
sional sounds. T hey did it all, okay? A nd 
all of this in well-behaved Windows 
applications. 

M aybe it is hypnosis, though. I need 
perspective and some feedback from you, 
our 20,000 editors. E-mail us at 
gdmag@mfi.com and tell us what to do. 
M ore graphics, more W indows, more A I , 
more design, more channel issues? It's your 
magazine— tell us what to do. ■ 

LarryO'Brien 
Editor 
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Delphi Why? 



by Our Readers 

This column is for your 
feedback. Send us 

queries, suggestions. 

complaints, and praise 
[especially praise]. 

You man! code? We've 
got code. [Really. 

Chech the end of this 
section for a special 

clip-and-save piece.] 



Dear Editor: 

Thanks for a magazine for developers of 
games. I just finished reading the 
April/May issue and have to question 
your editorial. What does Delphi have to do 
with game development? The magazine is 
thin enough without extra noise being put in. 

I also hope the magazine stays away from 
articles that compare games unless it's 
going to help me or someone else develop a 
game. Comparing Tetris on the SNES to Tetris 
on Sega doesn't do me any good, and I can 
read that in the hundreds of magazines 
devoted to games. 

Other than these few complaints, I really 
like the magazine. I hope it grows and 
becomes very successful. I feel that this 
magazine will be a valuable resource for my 
library. 

Brien King 
via e-mail 

Editor Larry O'Brien responds: 
Close your eyes and visualize this: "Games. 
Windows. " What do you see? A virtually empty 
universe, with Solitaire the brightest star. 
Now close your eyes and visualize this: "Win- 
dows. Home market. " What do you see? The 
fastest growing sector in the computer 
industry. Vast clouds of money being sucked 
faster and faster into the pockets of those 
who create digital entertainment. Delphi is a 
tool for those who want to become little neu- 
tron stars of dense money. 



DON'T FORGET THE MACINTOSH 
Dear Editor: 

A charter subscriber, I've been reading 
Game Developer since your premiere 
issue, and while you generally do a 



fine job on the article topics and writing in 
general, I am concerned about your blatant 
pro-DOS and Windows bias. (Why not just 
change the name to Windows Game Develop- 
erand avoid confusion?) 

I've developed on both PCs and Macin- 
toshes and greatly prefer the latter. The fact 
that there is a much larger market for DOS 
and Windows software than for Macintosh 
software is a tribute to Microsoft's market- 
ing abilities. However, Macintosh developers 
do exist, and we would like to read some 
articles pertinent to us. ..Mode 13 and Sound 
Blaster programming techniques are all well 
and good, but how about an article on pro- 
gramming .mods using Sound Manager? How 
about "Getting the Most Out of CopyMask?" 

Also, it would be a welcome addition if 
you'd state the platform on which a review or 
article is based. And please, try to get 
Alexander Antoniades to ease up — his com- 
ments in the April/May issueflt's a Sim, 
Sim, Sim, Sim World," By Design) suggested 
that Maxis was losing scads of money by 
developing on Macintoshes first. Maxis's 
success was probably due to the fact that it 
did write for the Macintosh, thereby avoiding 
the glut of games already available for the 
PC and distinguishing itself in a smaller 
market. Many other superior games (most 
notably, Myst) were developed on the Macin- 
tosh, and this platform should be given 
some consideration by your otherwise excel- 
lent publication. 

Geoffrey Reiss 
via e-mail 

Larry O'Brien responds: 
How about the best of both worlds, Macintosh 
and Windows? Jon Blossom shows how, starting 
on page 28. 
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IF I HAD MY OWN MAGAZINE... 
Dear Editor: 

Your magazine needs more mass to be 
worth buying. There are many things I'd 
like to see in future issues: 

• Two or three long interviews per issue (8- 
10 pages each). There are hundreds of 
people with much to say — designers, 
businesspeople, and the like. I'd like to 
read about Carl Stone's, Yoshihide 
Otomo's, Kim Cascone's, Mason Jones's, 
and Fumio Kosakai's electronic music 
recording methods. 

• I'd like a big report — interviews on Ultima 9 
Development, the Japanese game scene, 
Psygnosis's staff, and New World's staff. 

• I'd like to know what happened to Bill 
Hogue, Reflections, and Wizardry. 

• I'd like six to ten reviews and dissections of 
games new and old, game structure, archi- 
tecture, and the like. I've noticed that any- 
thing over two years old is being thrown off 
the shelves or deleted. Maybe you could 
print code architecture from these discon- 
tinued games. 

• I'd like 30 to 40 pages of articles on port- 
ing PC code to game systems, how it's 
done, and the troubles and costs of hard- 
ware. I'd like four to five pages per issue of 
screen shots from upcoming games, works 
in progress, and info on CD-ROM pressing 
and costs. 

Add in this junk and your mag will improve 
greatly. 

D. Godat 
Fort Wayne, In. 

Editor Larry O'Brien responds: 
Okay. .we'll get right on that junk. 



WELL, SOMEONE LIKES US 
Dear Editor: 

Thanks for such a great magazine. It is 
great to have articles from people who 
take the "theory" and put it into real 
world practice. In the April/May issue, I really 
liked Matt Pritchard's article, "Supercharging 
your Sprites" and Chris Hecker's column on 
perspective texture mapping. I also appreci- 
ate the business articles that talk about the 
game industry itself. 

Bruce Burkhalter 
Berkeley, Calif. 



Editor Larry O'Brien responds: 
Chris Hecker has a lot more to say on the sub- 
ject. See page 18 of this issue and look for 
more in the future. 



SOMEONE ELSE LIKES US, TOO! 
Dear Editor: 

I just wanted to say I like the direction in 
which Game Developer is going. In the 
April/May issue, you had not one, not two, 
but three great, informative articles — Chris 
Hecker's Under the Hood column, the first of 
two parts on texture mapping ("Perspective 
Texture Mapping Part I: Foundations"); "Pro- 
gramming Digitized Sound on the Sound 
Blaster" by Keith Weiner and Erik Lorenzen; 
and "Supercharge Your Sprites" by Matt 
Pritchard. Congratulations. 

The only thing I didn't like were Dean Ois- 
boid's opinions of Andre LaMothe's books 
Tricks of the Game Programming Gurus (SAMS 
Publishing, 1994) and Teach Yourself Game 
Programming in 21 Days (SAMS Publishing, 
1994). In contradiction to what the cover 
says, I think these books "do suck." But that 
is just a difference of opinion, not the fault of 
your magazine. 

Robert Zawarskl 
via e-mail 



WE GOT YOUR CODE RIGHT HERE 
Dear Editor: 

I normally do not offer unsolicited opinions, 
but in this case, I will. I used to be a game 
developer (I programmed The Last Files of 
Sherlock Holmes for 3DO). 

You should have it prominently displayed 
somewhere in your magazine that source is 
available via ftp. I learned this from your let- 
ters section. This could be my fault; I might 
have missed it somewhere. But it's a very 
handy piece of information. 

This last thing is a compliment. Your arti- 
cles were excellent — they all covered subjects 
that were interesting, up to date, and relevant 
to game programming today. There's no 
"Faster drawing in Mode X" stuff that was 
covered in Dr. Dobb's Journal three years ago. 
Texture mapping, ripping apart Tie Fighter, 
push-button game design. ..Yes! But, as I 
said before, give us more. 

Jeff Miller 
via e-mail 
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JHJT 

CROSSFIRE 



Alex Dunne 



Microsoft's Softimage 
is suddenlq chal- 
lenged bi| Silicon 
Graphics's merger 



niith Alios and Nave- 



front. What can game 
developers expect 



from these two? 



3D Graphics 
Go I laths 
Square Off 



Vesterday, as I was cleaning out a 
bookshelf in our office, I came 
upon an issue of Byte magazine 
from Aug., 1987. Although I 
was throwing everything away, 
I had an urge to flip through its 
pages— there's something com- 
pelling about a computer mag- 
azine that's over seven years 
old. Volume 12, number 9 
of Byte may only have been 
49 in dog-years, but it was 
much older in computer-years. 
I couldn't believe it— ads for 
386 16M hz computers sell- 
ing for $4,400, 9600-baud «- Competitive Partners 
modems for $1,000, and J '* w * t ^Q^*^J^g^ The relationship between 
articles about EGA graphics. It's 




Snow White and theSa/en Dwarves) into 
digitized EGA display. Yeeeesshhh, the 
final result looked horrible. So, maybe the 
time wasn't right back then for creating 
digital media from live footage. But, like a 
rolling snowball picking up size and 
speed, the graphics industry is maturing 
to the point where there's not too much 
anyone can't do at an affordable 
price. M icrosoft and Silicon 
G raphics (SG I ), thanks to 
recent acquisitions and merg- 
ers, are helping to fuel this 
momentum. 



amazing we got through those rough 
times. (Some know-it-all will read this in 
2002 and say the same thing about 1995, 
no doubt.) 

O ne article that caught my eye 
focused on the technique of transferring 
cartoon- quality film (a clip from D isney's 



M icrosoft and Silicon 
G raphics has changed enormously over 
the past 12 months. Silicon Graphics is 
the dominant player in the graphics 
workstation market, and M icrosoft is the 
giant in the PC software market. H owev- 
er, when M icrosoft acquired Softimage 
last summer, M icrosoft gained a powerful 




Man in the boat overboard! Softimage Toonz, which was used to create this animation eel, is 
one product in a suite that Microsoft acquired last year. The software currently runs on the 
SGI platform, but Microsoft has stated its plans to port Softimage tools to Windows NT. 
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suite of IRIX-based animation, editing, 
compositing, and eel animation tools. It 
instantly became a key partner of SG I . 
Eight months later— last February— SGI 
merged with Alias and W avefront, two 
companies that compete against Softim- 
age on the SG I platform. H ow have these 
developments changed the relationship 
between Silicon Graphics and M icrosoft? 
M ore importantly, how does it affect their 
customers? 

I spoke with Andrew W right, group 
product manager of advanced authoring 
tools for M icrosoft/Softimage, and Dave 
Larson, director of marketing for Silicon 
Studios, a wholly owned subsidiary of Sili- 
con G raphics, about the actions their 
companies have taken recently in the digi- 
tal entertainment industry. 

The most recent event, Silicon 
G raphics' merger with A lias and W ave- 
front, achieved two objectives for 
SG I, according to Larson. 

"W e felt that by merging 
with Alias and W avefront," Larson 
explained, "we could get two of the 
most important groups of engineers 
together with our engineers and accom- 
plish two things. [The first objective] is to 
drive the development of our 3D software 
environment... [Second,] we don't have 
expertise in entertainment and industrial 
[software] markets at the customer level 
like we do with hardware. W e're getting a 
sales force that knows the customers really 
well at the application level, a sales force 
that has a much greater depth of knowl- 
edge." 

W hat was W right's reaction to the 
SG I merger? 

"Surprise," he said. "From 
[M icrosoft's] perspective, it actually puts 
us in a stronger position because we feel 
that for our customers a cross- platform 
solution is important. W here they want 
the performance of SG I , we provide it, 
where they want the price- to- performance 
ratio and openness of a W indows NT sys- 
tem we'll provide that to them. W e'll be 
the only high-end 3D animation vendor 
that's effectively able to execute a cross- 
platform strategy." 

I sensed no edginess from either 
W right or Larson about the relationship 
between M icrosoft and SG I , and both 



played up the positive aspects of their 
new product lines. Wright stressed the 
fact that many of SG I 's partners, not just 
M icrosoft, were now competitors, but 
that it wouldn't make sense for SG I to 
consider them as such: "Yes, we are a 
competitor to [Silicon Graphics], but 
they're also a competitor to a number of 
their other ISVs [independent software 
vendors]. Companies like Side Effects, 
Discreet Logic, Avid... One thing I can 
say absolutely outright is that if SG I loses 
their third- party applications as a result 
of this merger, they're dead in the water. 
I think they've almost got to overcom- 
pensate to make sure that their third 
party ISVs are treated fairly," W right 
commented. 

Dave Larson adamantly agreed. 
"W e're going to treat [M icrosoft] as we do 
a whole category of partners who will get 

] early access information, and it's 
based on business parame- 
ters. These guys, as well as 
other 3D vendors, are still 
selling SG I software and 
we're going to do whatever we can to 
make sure they continue to do so. That's 
our business" 




Softimage off 
the SGI Platform? 

Upon acquiring Softimage last year, 
M icrosoft stated its intention to port the 
Softimage tools over to W indows NT. I 
asked W right whether M icrosoft had 
plans to pull Softimage products off the 
SGI platform at a later date and focus 
exclusively on its own operating system 
implementation. 

"No. One of the key reasons 
M icrosoft bought Softimage is that Soft- 
image had a tremendous presence in the 
community that was producing the 
world's best content. I L M [I ndustrial 
Light and Magic]. Greenberg. Rocket 
Science. For those companies, the SGI 
platform is absolutely critical because they 
need that level of performance... W e think 
W indows NT and the associated hard- 
ware developments are going to provide a 
very price-attractive alternative. But in no 
way is that going to put SG I out of busi- 
ness. T hey are going to continue to do 
very well and we need to be there." 



M icrosoft looks at its partner/com- 
petitor relationship with SG I in the same 
light as its association with Apple. "We'll 
continue to invest in SG I ," W right stated. 
"It's very similar to our situation on the 
M acintosh. M icrosoft makes a lot of 
money on the M acintosh and it's a very 
vital platform for us at the application 
level, even though we don't own the oper- 
ating system. T he fact that we've got 
applications on W indows 95 as well does 
not in any way affect our investment in 
theM acintosh platform." 

Wright sees Silicon Graphics 
remaining the superior platform for high- 
end digital video and three-dimensional 
animation over W indows N T , just as the 
M acintosh held its position as the superior 
platform for graphic design when Win- 
dows 3.0 was introduced. 

"M acintosh had a very strong posi- 
tion in graphic design. W indows came in 
and everybody thought that it was going 
to completely take over the market. Asa 
result, companies like Aldus and Adobe 
developed their applications first on W in- 
dows and second on M acintosh. But they 
realized over time that the M ac wasn't 
going to go away... We think a simi- 
lar thing is going to hap- 
pen in the SG I world," 
W right said. 



Porting Softimage 
Products to Windows NT 

Upon acquiring Softimage, M icrosoft 
announced that it would port the compa- 
ny's toolset to W indows N T . W right 
indicated that Softimage products would 
be available on W indows NT this year, 
but he declined to be more specific, fear- 
ing that divulging an estimated date could 
raise false hopes. 

I wanted to know what strengths 
Windows NT could offer over the SG I 
platform to game developers. After all, 
SG I has been targeting this market for 
years and has optimized its hardware for 
high-end graphics and animation. W right 
responded: "W e think that the W indows 
NT platform will offer very attractive 
price- to- performance ratio in the range of 
performance that it delivers. W e also feel 
that for people who have PC -based net- 
works, for example developers who are 
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using [Autodesk's] 3D Studio, it will be 
important for them to run a high-quality 
3D product in the same environment that 
they're running their other tools. I think 
that's going to be key to the games devel- 
opment area." 

Downward 
Pressure on Prices 

In addition to announcing the porting of 
Softimage tools over to W indows NT, 
M icrosoft announced in January that it 
was slashing the price of all Softimage 
software by up to 50%. W hat was behind 
this aggressive move? W right explained: 

"Over the last couple of years, inter- 
active developers [have 
begun to] require [high- 
end] tools as games have 
become more sophisticated. We looked at 
our pricing structure and said, W ell, those 
prices make sense if we continue to main- 
tain our high-end feature set for our tradi- 
tional market.' But if [M icrosoft] really 
wants to penetrate the market for game 
developers as well as other emerging inter- 



active media, it's important to have more 
aggressive price points and maintain that 
leadership position." 

A large number of graphics 
and animation products have fZ 
been launched for the W indows, 
DOS, and M acintosh platforms 
recently by companies like Caligari 
and Strata. Although these products 
aren't in the same class of function or 
performance as either the M icrosoft or 
SG I tools on IRIX, they seem to be exert- 
ing pressure on software prices for the 
entire market, regardless of platform. I 
asked Dave Larson how Silicon Graphics 
viewed these lower- priced products, and 
how his company would respond. 

"W e're moving down in 
terms of markets," declared Lar- 
son. "As our price points come down, 
we're cutting deeper into various mar- 
kets... H istorically, SGI has been per- 
ceived as vastly more expensive and out of 
reach, a boutique kind of machine. We 
think we're rapidly expanding beyond 
that, and that we're within reach for a lot 




of people [developing digital entertain- 
ment] for a living. It's all about how much 
time you have to get your work done. For 
instance, a friend of mine just 
came up who's been doing a lot 
of audio work on the M ac, 
and he just started using a 
new audio application on 
our platform. H e says it's 
dramatically affected his work just after a 
few days of working with it. W hat he used 
to think ahead to do he now does in real 
time. H e can test his decisions as he goes 
That's the metaphor for performance 
change. Everything happens so much 
more quickly [on the SGI platform], and 
your creativity can increase." 

Sega and 

Nintendo Choose Sides 

There's an interesting sidebar concerning 
SG I and M icrosoft. T he two archrivals in 
the game cartridge market, N intendo and 
Sega, have gone to separate corners for 
their respective development tools, and you 
can probably guess whom each has enlist- 
ed. In 1994, Nintendo selected Alias 
(whose software was used to create the 
Super NES blockbuster Donkey Kong 
Country) as the authorized graphics devel- 
opment system for both current games and 
next- generation 64-bit games. Last Janu- 
ary, Sega chose Softimage 3D as the offi- 
cial three-dimensional development tool 
for the new SegaSaturn game platform. 
I 'm not saying that this is an instance of 
"any enemy of my enemy is my friend," but 
it is predictable political maneuvering. 

As long as the Softimage tools on 
IRIX don't take a distant second priority 
to their W indows N T version, users stand 
to gain from a price war between two 
resource- rich companies like Silicon 
G raphics and M icrosoft. Feature sets and 
performance should evolve more rapidly, 
and it undoubtedly will spur other SGI 
platform competitors to keep up. 

You'd better get used to seeing more 
companies merging or acquired as the dig- 
ital entertainment market expands— it's a 
natural consolidation that should continue 
for the next couple of years. ■ 



Alex D unne is contributing editor for 
G ame D eveloper magazi ne. 
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BIT BLASTS 



Live from 
the CGDC 
Show Floor! 



Game 
■Developer Staff 

If mas some show! 



Alexander Rnfoniades 
kepi an eye on the 
tenor of the shorn. 
Larry O'Brien and 
Barbara Hanscome 
checked out new prod- 
ucts. And Nicole Claro 
ran into her cosfar from 
the high school play. 



For those souls lucky enough to 
get in, the CGDC usually has 
enough information to make it 
the best show for both the sea- 
soned and prospective game 
developer, and 1995 was no 
exception. M ushrooming up to 
2,500 attendees, the CGDC 
irked prospective conference goers by 
severely underestimating demand for the 
second year in a row, so anyone who 
didn't buy tickets (or register as press) 
well in advance of the show has to read 
about it here and hope they didn't miss 
out on too much. 

The main buzz was about the 
CGDC show itself and revolved around 
founding member C hris C rawford's talk 
on the second day. Crawford railed 
against show management and admitted 
that he had been kicked off the board of 
directors. It was a sad note to this show, 
which started nine years ago in someone's 
living room and has grown larger than 
anyone would have thought possible. 

W hile last year's "unofficial" theme 
was the invasion of H ollywood money 
and fear of ratings, the definite themes 
this year would have to be three-dimen- 
sional development and the move to 
W indows. M ost of the exhibitors were 
hawking three-dimensional tools (both 
sight and sound), offering to turn you 
into the next industry superstar if you'd 
just buy their tool (and the box— usually 
a RISC one— it runs on). On the Win- 
dows side, M icrosoft explained its new 
write- to-the-device-drivers interface and 
showcased its recent acquisitions Render- 
M orphicsand Softimage. 

Lurking in the shadows, other plat- 
form vendors vied for a piece of the home 



entertainment pie, hoping that M icrosoft 
might stumble in the rocky transition 
from D S to W in32. A pple showed 
Doom and Dark Forces running native 
on Power Macintoshes, and IBM 
announced an OS/2 Warp game devel- 
oper's kit and help from Argonaut and 
M acromedia. Dave Taylor of Id put the 
whole platform thing in perspective when 
he said the fastest version of D oom is the 
Linux version, so maybe there are 
untapped opportunities after all. 

I n an industry with its share of egos 
and superegos, the Freudian slip still 
crossing most developers lips remains Id. 
The folks from M esquite, who received a 
standing ovation from awestruck devel- 
opers last year, were out in force this year 
offering private showings of their next 
project, Quake, to developers deemed 
worthy. For an industry that uses Doom 
as benchmark, Quake becoming a hit is 
probably the only prediction that anyone 
can make for sure. 

Low-Cost Wavetable Sound 

HM D , the fourth- largest supplier of 
ICs in the U.S., was showing its 
new A M 78C 201 I nterW ave audio 
processor, a kick-butt, single-chip 
audio system. At its hospitality suite, 
AMD demonstrated prototype sound 
boards with component costs as low as 
$40 (implying a sub- $100 street price) 
running under popular games such as Tie 
Fighter and recreating beautiful sym- 
phonic arrangements. AM D is enthusi- 
astic about the M icrosoft G ame SD K, as 
was rigin's Zachary Simpson, who said 
T he I nterW ave chip and the M icrosoft 
DirectSound API will allow. ..unprece- 
dented levels of audio quality and realism 
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at consumer price points." H oo doggie, 
this is one nice chip with its 16- bit, 32- 
voice wavetable synthesis and on-chip 
support for vibrato, tremolo, chorus, 
echo, phase shifting, and reverb. L ook for 
boards with this chip to be available and 
flying off the shelves for C hristmas 
For more information contact: 
AMD Inc. 
1 AMD PI. 
P.O. Box 3453 

Sunnyvale, Calif. 94088-3453 
Tel: (408) 732-2400 

The O.J. Files 

BioVision, of San Francisco, is a 
turnkey motion capture service 
provider. Inverse kinematics isn't 
time- effective for complex human 
motion, but with B ioV ision's low-cost 
service, you can have rotoscoped actors 
that can be disturbingly realistic (you 
might have seen BioV ision's work in the 
frightening recreation of the murder of 
N icole Simpson and Ronald Goldman 
that's making the rounds on the I nternet) 
or thrilling (as in a certain wildly popular 
football game). For every day of shooting, 
BioVision estimates two days of post- 
processing to massage the data into for- 
mats for popular animation packages such 
as Alias, Softimage, Wavefront, and 
Nichimen Graphics. BioVision will even 
supply the actors! If you don't need cus- 
tom work, BioVision has partnered with 
Viewpoint DataLabsto provide over 200 
standard motion sets. 
For more information contact: 
BioVision 
1580 California St 
San Francisco, Calif. 94109 
Tel: (800) 866-3463 



VIOLENCE IS FINE — BUT HUH ELSE IS HEBE? 



If you were at the right place at the right time at the CGDC this year (the lobby of the 
Westln Hotel at 5:30 on Sunday), you might have been asked to join an Informal round- 
table discussing game strategies that appeal to a broader audience- namely women 
and nontradltlonal game players. J ust what kind of games appeal to game players who 
aren't 18- to-35-year-old men? And what can game designers do to reach them? 

J esslca Miller, game designer and president of Spirit Games In Salem, N.H., and myself were 
lucky enough to be so well positioned In the lobby, and for the next two hours we chatted 
with three game designers Interested In bursting out of the "shoot-and-klll," model: Alex 
Uttermann, game designer and author of several game strategy books (Including Dragon 
Lore: the Official Strategy Guide), Rusel DeMarla, game Industry journalist and president of 
DeMarla Studio, and Dennis Hescox, vice president of Lightslde Inc. 

Hescox organized the roundtable In hopes to build a network, share Information, and discuss 
marketing development and research strategies for alternative games. He came armed with 
psychological and academic theories and studies relating to differences between male and 
female game playing styles, neurophysiology, and perceptual physiology. "By understanding 
these differences, " Hescox explained, "we can attempt to design entertainment based on 
some solid Ideas rather than vague and cosmetic guesses"- like pink Interfaces and ponies 
on a box. 

The conversation quickly jumped from theories to games that are simply fun to play. Utter- 
mann, who Is working on a game with DeMarla that she hopes will have an Internal logic 
that appeals to both genders, summed It up nicely In saying, "Violence Is fine In games, but 
what else Is there?" 

Puzzles that are fun to solve on their own but connect to help solve a larger puzzle; Interac- 
tive games that require good communication skills and diplomacy to "win," rich plots that 
unfold like a novel, role-playing games, "safe environments" that allow the player to con- 
quer the task at hand comfortably before moving on to the next challenge, and networked 
play were all mentioned as games and elements that would appeal to female as well as 
male game players. 

By the time we got around to how to convince the big companies In the Industry to take 
some risks with these types of games, the hospitality suites were calling our names. But I 
think we could have talked all night. And I also think more people In the lobby would have 
joined us If they could. Perhaps we needed to hold up a big sign- If only we had a name for 
just what It was we were discussing. It was obvious by the end of our chat that "games for 
women" wasn't exactly It. 

If you have thoughts and comments pertaining to women's games and alternative gaming 
strategies, contact Barbara Hanscome at 73611,633@ compuserve.com. 
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Mapping, Part II: 



Figure 1. The Fill Convention 
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Did I say I 'd be doing two 
columns? Silly me— I meant 
four or five columns. ur 
topic, perspective texture 
mapping, is so huge I don't 
know what I was thinking 
when I said we could cover it 
completely in two columns. 
Luckily, the topic has enough variety 
that it should keep everyone glued to 
these pages for the duration. 

In Part 1, we covered most of the 
math behind the perspective projection 
and triangle gradients (those neat num- 
bers that let us interpolate without 
recalculating at each scan line), and we 
quickly went over polygon fill conven- 
tions and stepping on pixel centers. 
That's a lot of information for a single 
article. I n fact, there's so much material 
still to cover I'm not even going to 
summarize my last article beyond say- 
ing, "Read it." If you haven't read Part 
I , you'll still get a lot out of Part 1 1 , but 



you might have trouble seeing how this 
information fits in perspective (cough). 

This time around we're going to 
focus on the triangle rasterization stage, 
and we'll expand on the math for the 
fill convention we derived last issue. 

As I did last time, I encourage you 
to get out a piece of graph paper and 
join in the fun. Speaking for myself, I 
find it impossible to learn math with- 
out scribbling all over the place. 

If you don't like math, well, com- 
puter graphics is math for the most 
part, so I'm not sure what to tell you. 
M y goal is to describe the math in an 
accessible way, but I'm not going to 
hide the fact that math underlies every- 
thing about computer graphics, espe- 
cially three dimensional computer 
graphics. If you like programming you 
will definitely like math. ..heck, math's 
even better than computer program- 
ming because there are no compiler or 
operating system bugs! (Of course, 
there's no compiler or operating system 
to tell you when you've done something 
wrong, either.) 

Raster Blaster 

W hen I say rasterization, I mean taking 
the continuous geometric triangle- 
defined by its vertices— and displaying 
it on the monitor's discrete display grid, 
or "raster." The rule we defined for 
doing this is called a top-left fill con- 
vention, where we light all pixels that 
are strictly inside the polygon bound- 
aries and any pixels that are exactly on 
the polygon boundary if they're on the 
top or left edges (remember, pixels are 
boxes with a center, not just points). 
Figure 1 shows this fill convention in 
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action. Pixel (5,2) is lit, but pixel (9,4) 
is not, even though our polygon edge 
intersects both (within the limits of the 
magazine's printing accuracy, at least). 
This is because (5,2) is on a left edge 
and (9,4) is on a right edge. A fill con- 
vention lets abutting polygons share an 
edge without either polygon overwrit- 
ing any pixels of its neighbor, or leav- 
ing any unlit holes— called dropouts— 
between the two. 

A top-left fill convention for a left 
edge from xO.yO to xl.yl is defined 
mathematically by the ceiling function: 



X int _ 



( 



x i x o 



(y- y )+x c 



yi - y ; 

In my last column, I presented this 
equation without much explanation, so 
this time we'll go into it in more detail. 
First, we can derive the equation for 
the line in Figure 2 by setting the slope 
of the entire line equal to the slope of 
any line segment on that line (the seg- 
ment from x,y to x ,y is on the line, so 
its slope is equal to the line's) and solv- 
ing for x: 



y? -yo _ y-yp 

X\ — X2 X — Xq 



(2) 



W e can use E quation 2 to give us the x 
value for any y value on the line. You 
can see that if y = y , then x = x as 
you'd expect, and likewise for the other 
endpoint. This equation generates real 
(as opposed to integer) values for x, so 
we need to use our fill convention to 
tell us how the real x maps to an inte- 
ger pixel. This is where the ceiling 



function comes in. 

The ceiling function is defined as 
bumping a real value up to the next 
highest integer if the value has a frac- 
tional part, or leaving it alone if it is 
already an integer. For example: 



1 



and: 

N otice how the ceiling behaves with 
negative numbers— it bumps the value 
to the next highest value, not to the 
next highest absolute value. 

T he ceiling is the perfect function 
to realize a top-left fill convention for 
left edges (and top edges if you solve 
for y instead of x in Equation 2). If 
we're exactly on an integer pixel center 
we will light the pixel, but if our x is at 
all greater than the integer— to the left 
of the pixel center— the ceiling will 
bump us up to the next pixel that's 
strictly inside the edge. It should be 
pretty obvious that the equations for 
right and bottom edges are the same as 
for top and left edges with the addition 
of a minus one outside the ceiling. 
That is, if the edge is on the integer 
pixel, the ceiling won't affect it, but the 



Chris Hecker 

Perspective texture 
mopping is a huge 
subject — much too 
big to cover in one or 
even tuio articles. In 
Port II of his series on 
the subject. Chris 
Hecher tackles 
rasterization, an 
essential concept. 
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minus one will knock us back one pixel 
following our fill convention. If the 
edge is greater than the pixel, the ceil- 
ing will bump it up one (to the first 
pixel outside the edge) and the minus 
one will bump it right back inside the 
polygon. Another way of looking at it 
is if we have two polygons with an 
abutting edge, the edge will be the left 
edge of one and the right edge of the 
other (or the top and the bottom), and 
they'll draw the same set of pixels, 



Figure 2. A 2D Line 




except offset by a single pixel for one 
polygon. 

The code to implement this was 
pretty straightforward in our floating 
point rasterizer (shown in last month's 
listing): 

int XStart = ceil(pLeft->X); 

W e call the AN SI standard 
math.h function, ceilO, and use the 
integer returned for our starting x coor- 
dinate. As we step from one scanline to 
the next our real x value steps by the 
inverse slope, as Equation 2 shows 
when you set y =y + 1. 

While floating- point math cer- 
tainly is convenient when you're trying 
to get code up and running, it's proba- 



bly not the best choice for a produc- 
tion rasterizer. First, even though 
floating point coprocessors are com- 
monplace on today's machines and are 
even faster than the integer processor 
for some operations, converting from 
floating point to integer is still slow. 
Because a rasterizer is where the real 
three-dimensional coordinates get 
mapped to the integer hardware 
bitmap, we end up converting a lot. 
Also, functions like ceilO are actual 
function calls in floating point, but fall 
out of the math almost for free with 
integer coordinates. 

In addition, it's hard to get the 
math just right for floating point num- 
bers; there's a whole field in mathemat- 
ics dedicated to figuring out how float- 
ing point numbers accumulate error. 
Finally, we'll see there are some bene- 
fits to using integer digital differential 
analyzers (DDAs) when we discuss 
pixel centers. 

Integers from 
Floor to Ceiling 

Before we convert our rasterizer to use 
integers, let's learn a couple of neat 
tricks for manipulating the ceiling 
function and its companion, the floor. 
The floor of a value is— you guessed 
it— the next-lowest integer if the value 
has a fractional part, or the value if it's 
already an integer. You could also think 
of this as truncating the fractional part 
for positive values. Following are some 
floor examples: 



LiJ- 
L*J~> 

and 

Again, notice the behavior when the 



value is negative. 

We can convert from ceiling to 
floor easily if a and b are integers: 

[fH^J +1 = (3) 

Equation 3 also shows that we can 
move integers in and out of the floor 
(or ceiling). We obviously can't move 
fractional values in and out, though, 
because they can affect the result. Run 
through a few examples on your own to 
see why E quation 3 works. 

Now that we have a working 
knowledge of floors and ceilings, let's 
convert the rasterizer to use integer 
coordinates. Because we are defining 
x ,y and x 1 ,y 1 in Equation 1 to be 
integers, we can manipulate the equa- 
tion to our advantage. W e can bring x 
outside the ceiling function, for 
starters. T his means any x generated by 
our fill convention will be the integer 
x plus the integer result of the ceiling 
function for a given y. Now, let's use 
E quation 3 to turn the ceiling function 
into a floor. 

Let: 

dx — X\ — Xq 
and: 

dy = yi- y 



so: 



My - yo) - 1 

dy 



+ l + x (4) 



If our initial y value is y , it's easy to see 
the initial value in the floor is -1/dy. 
T he floor of this is -1, and -1 +1 +x = 
x , as we expect. W e'll be doing for- 
ward differences to step our edges, so 
after we generate the initial value for x, 
we're going to want to step y by 1 to 
the next scanline and generate the next 
x from our previous x value, without 
recalculating it from scratch. I will 
assume you are already familiar with 
forward differences, which are covered 
in any decent computer graphics book, 
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so I 'm just going to point out the inter- 
esting parts of this algorithm. 

Perhaps the most interesting thing 
about this particular equation is how the 
floor interacts with the forward differ- 
ences, especially when dx is less than 0. 

Mod Squad 

To thoroughly analyze Equation 4's 
behavior, we need another trick for 
manipulating floors: 

I a I a a mod b , c „^ 

[b\ = b h— (5a) 

You're probably familiar with the modu- 
lus operator, mod, from programming in 
C or other languages (in C , % is the 
mod operator). As long as two numbers, 
a and b, are positive, a mod b is the 
integer remainder after dividing the 
numerator a by the denominator b. 
E quation 5a says we take the real num- 
ber a/b and subtract its remainder over b 
and to get the floored value, an integer. 

The mathematically defined mod 
usually behaves differently, in subtle 
ways, than the mod in your program- 
ming language of choice, and because 
we're using the "math-mod" in the defi- 
nition of our fill convention we need to 
make sure we don't let an ill defined 
programming language muck up the 
works. For example, ANSI C (and 
C++) defines the mod operator to be 
the same as the math-mod operator 
when both operands are positive, but 
when either operand is negative the 
result is implementation dependent— 
the standard only defines the relation- 
ship of a/b and a%b, not their values, in 
this case. Fortunately our denominator, 
dy, is always positive because we step 
down the polygon from top to bottom, 
so we only have to deal with the case 
where the numerator, dx, is negative. 

W e saw how the floor function 
behaved with negative values, so if 
E quation 5a is true (it is, trust me), that 
dictates how the math-mod behaves as 
well. Assuming b is positive (our dy), a 
little thought and some scratch paper 
will show you that a mod b is always 
positive regardless of whether a is posi- 
tive or negative. This is because the 



floor of a negative number goes to the 
next lowest number, so the mod term 
must be positive to bring it back up to 
the real value of a/b. Figure 3 shows a 
graph of x mod 3. H ere's Equation 5a 
rearranged to make that more clear: 

a = ^ + amodb (5fc) 

Equation 5b shows a fraction as we 
sometimes think of it with an integer 
part and a fractional part, since a mod b 
is always smaller than b. 

Even if we want to ignore the 
ANSI standard and hope our platform 
calculates mod correctly, we're out of 
luck on most machines, including I ntel 
x86 processors. The x86 signed divide 
instruction, idiv, truncates towards 
when dividing negative numerators, 
which is exactly the opposite of the real 
floor function. It appears we need to 
develop a flooring divide and mod 
function that works on any standard 
platform, that is, any platform that 
computes positive mods and divides 
correctly. 

I f a > 0, then we'll just do the nor- 
mal divide and mod. On the other 
hand, if a < 0, let m =(-a) mod b: 



Figure 3. x mod 3 





(-a) 
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(-a) 




b J 



f 0,m = 
a mod b = < O) 
[b - ((-a) mod b), nvtO 

In other words, Equations 6 and 7 say 
that if m = (there is no remainder), 
then we do the flooring divide and mod 
differently than if there is a remainder. 
This probably seems really complicat- 
ed, but if you sit down with a piece of 
paper and refer to the equations and 
Figure 3 you'll see how this works in no 
time (okay, maybe five or ten min- 
utes.. .it took me a while, too). Our 
C++ function to correctly compute 
flooring divides and mods looks like 
this: 

inline void FloorDivMod( long Numerator, 
long Denominator, 
long &Floor, long Mod ) { 
assert(Denominator > 0); 
// ue assume it's positive 

if(Numerator >= 0) { 
// positive case, C is okay 

Floor = Numerator / Denominator; 
Mod = Numerator '/, Denominator; 
} else { 

// Numerator is negative, 
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do the right 
thing 

Floor = -((-Numerator) / Denomina- 
tor); 

Mod = (-Numerator) '/, Denominator; 
if (Hod) { 
// there is a remainder 

Floor--; Hod = Denominator - Plod; 

} 

} 

} 

Why? 

Let's take a step back and ask ourselves 
(as you're probably already asking your- 
self), "Why do we care?" People have 
been rasterizing polygons since shortly 
after the beginning of time, and they 
never went through all this, you say. 
Well, if their polygons don't have 
dropouts and consistently light the cor- 
rect pixels, then they went through all 
this or its equivalent for another fill 
convention. 

The vast majority of rasterizers 
don't work properly, and that's why the 
vast majority of games have dropouts 
and overwrites at abutting polygon 
edges. W e're taking the time up front 
to get the math exactly right, so we can 
implement our rasterizer with total 
confidence that it will light exactly the 
right pixels; no more, no less. 

This is my personal crusade to 
eliminate dropouts and poor quality 
rasterizers everywhere, and I'm hoping 
you'll help me accomplish it. The best 
part about doing it right is it looks bet- 
ter and isn't any slower at run time 
than doing it incorrectly, there's just 
more to understand beforehand. 

Vive La Difference 

N ow that we've got an algorithm for the 
correct divide and mod on any platform, 
we can go back to our original goal, 
which was to implement our fill conven- 
tion with integer forward differences. 
We can use Equation 5b to manipulate 
E quation 4. L et n =dx(y - y ) - 1: 



n 

dy. 



n mod dy 

. dy . 



+ l + x 



^•int 



and 



n 


n mod dy 


_[dy_ 


+ dy "1 



(W e can take the floor of n/dy out of 
the enclosing floor because it's an inte- 
ger; see Equation 3.) 

T his is our initial state. W e calcu- 
late n from our starting y value, do the 
flooring divide and mod (with our cor- 
rect algorithm if n is negative), and use 
the n mod dy term's numerator as our 
initial error term for our forward differ- 
ence. (W e don't actually do the divide. 
It's implicit in the way the D DA func- 
tions.) Since n mod dy is positive and 
less than dy, we know that the floor of 
the n mod dy term is and doesn't 
affect the initial x. Asy steps by 1, our 
floor term steps by dx/dy (calculated by 
substituting y = y + 1 in our original 
equation). ur new x (call it x'), is cal- 
culated from: 



n mod dy | dx 
dy dy 



W e use E quation 5b on the dx/dy step 
to get: 



dx 
dy. 

n mod dy dx mod dy 



(8) 



+ 1 + x 



dy dy 

E quation 8 says that as y steps by 1, x 
steps by the floor of dx/dy, and our 
error term steps by dx mod dy. N ote 
that mod is always positive, so when 
our error term numerator exceeds our 
denominator, dy, we add 1 to the 
resulting x regardless if we're stepping 
left or right. T his probably differs from 
other DDAs you've used before— the 
mathematically defined floor and mod 
terms work out so that you're always 
adding 1 when your error term rolls 
over, not just when you're stepping in 
the positive direction. 

Look Before You J ump 

Those of you who have written fixed- 
point edge rasterizers instead of error- 
term DDAs are probably wondering 
why we're going to the trouble of doing 
a DDA, with its accompanying jumps 



when the error term rolls over. Even 
though the jump is in the scanline 
loop, not the pixel loop, jumps are get- 
ting more and more expensive as 
processors get deeper and deeper 
pipelines. In fact, on more recent Intel 
architectures the jump prediction logic 
makes mispredicted jumps that fall 
through even more expensive than 
jumps that are taken on earlier proces- 
sors. Fear not, there is a good reason to 
use an error-term DDA instead of 
fixed- point to scan our edges. 

Remember the following lines 
from our floating-point texture mapper 
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in Part 1: 

int XStart = ceil(pLeft->X) ; 
float XPrestep = XStart - pLeft->X; 
float OneOverZ = pl_eft->OneOverZ + 
XPrestep * Gradients. dOneOverZdX; 

W hen we start a scanline, we need 
to step in to the first pixel center from 
the real edge before we can start draw- 
ing, and our interpolants (like 1/z in this 
snippet) need to step with us. W e had to 
calculate XPrestep every scanline, and 
multiply it by the gradients of all our 
interpolants to get to the starting pixel 
center before we could draw. This is 
because we didn't know how far we were 
from the first pixel center until we did 
theceilO call. 

Now think about how this works 
with a D D A. W e are stepping from one 
pixel center to the next directly, and we 
know exactly how far we had to come 
from the last pixel center: the floor of 
dx/dy in x plus 1 in y, or that step plus 1 
in x when our error term rolls over (see 
Equation 8). W e never need to calculate 
our prestep to a pixel center because 
we're always stepping on pixel centers! 
Take a minute to think this through— it 
means we get the advantages of sampling 
from pixel centers, and we don't pay the 
prestep multiply. As I've mentioned 
before, these advantages include rock 
solid textures that don't swim when you 
rotate and no "hairy texture" artifacts. 

L isting 1 shows the salient parts of 
the integer rasterizer. Because of space 
constraints, I've only included the dif- 
ferences from last column's listing. You 
can pick up the entire listing on Com- 
puServe in the Game D eveloper section 
of the SD Forum or from 
ftp://ftp.mfi.com/gdmag/src/. 

T he code is in a weird state because 
I left the texture coordinates as floats, 
while the edge rasterization is in integer 
coordinates, as we've been discussing. 
This bizarre combination doesn't affect 
the rasterizer, and it will be fixed in the 
next article when we address the texture 
mapping itself. One thing you may or 
may not notice when you run this raster- 
izer is how jerky it is compared to the 
original floating point rasterizer. If you 



Listing 1. The Integer Rasterizer (Continued on p. 26) 



struct edge { 

edge(gradients const ^Gradients, P0INT3D const *pVertices, 

int Top, int Bottom ); 
inline int Step( void ); 

long X, XStep, Numerator, Denominator; // DDA info for x 

long ErrorTerm; 

int V, Height; // current y and vertical count 

float OneOverZ, OneOverZStep, OneOverZStepExtra;// 1/z and step 
float UOverZ, UOverZStep, UOverZStepExtra; // u/z and step 
float VOverZ, VOverZStep, VOverZStepExtra; // v/z and step 

}; 

inline int edge::Step( void ) { 
X += XStep; Y++; Height—; 
UOverZ += UOverZStep; VOverZ += VOverZStep; 
OneOverZ *= OneOverZStep; 

ErrorTerm += Numerator; 
if (ErrorTerm >= Denominator) { 
X++; 

ErrorTerm -= Denominator; 
OneOverZ += OneOverZStepExtra; 

UOverZ += UOverZStepExtra; VOverZ += VOverZStepExtra; 

} 

return Height; 

} 

void DrawScanLinet BITHAPINFO const *pDestInfo, BYTE *pDestBits, 
gradients const ^Gradients, edge *pLeft, edge *pRight, 
BITHAPINFO const *pTextureInfo, BYTE *pTextureBits ); 

/******** TextureMapTriangle **********/ 

/*»****»**♦ handle floor divides and mods correctly ***********/ 

inline void FloorDivHod( long Numerator, long Denominator, long JiFloor, 
long Mod ) 

{ 

assert(Denominator > 0); // we assume it's positive 

if (Numerator >= 0) { 

// positive case, C is okay 

Floor = Numerator / Denominator; 

Hod = Numerator '/, Denominator; 
} else { 

// Numerator is negative, do the right thing 
Floor = -((-Numerator) / Denominator); 
Hod = (-Numerator) '/, Denominator; 
if(Mod) { 

// there is a remainder 

Floor—; Hod = Denominator - Hod; 

} 

} 

} 

/»»****»*** edge constructor ***********/ 

edge::edge( gradients const ^Gradients, P0INT3D const *pVertices. 
int Top, int Bottom ) 

{ 

Y = pVertices[Top].Y; 

Height = pVertices[Bottom].Y - Y; 

int Width = pVertices [Bottom]. X - pVertices[Top] .X; 

if(Height) { 

// this isn't necessary because we always start at TopY, 
// but if you want to start somewhere else you'd make 
// Y your start 

FloorDivHod (Width * (Y - pVertices[Top] .Y) - 1, 
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compile two test programs, one with each 
rasterizer, and run them side by side, 
you'll easily seethe quality difference. 

The texture mapping is jerky 
because we use the endpoints of the tri- 
angle to compute the gradients, and the 
endpoints are changing by relatively large 
amounts as the triangle moves because of 
the integer truncation. You also see simi- 
lar jerkiness in a lot of game rasterizers, 
and it's probably caused by the same 
thing (compounded with the artifacts 
generated by not stepping on pixel cen- 
ters). Even in the low 320 by 200 resolu- 
tion game world, this jitter is visible sep- 
arately from the normal aliasing. In 
accordance with our quest to increase 
rasterization quality around the world, I 
find this unacceptable. T he solution hap- 
pens to be simple: fractional endpoints. 
U nfortunately, I was out of space a while 
back, and my editor is beginning to hate 
me, so the description of this solution 
will have to wait until next time. 

Summing Up 

Once again, I'm over my word budget, 
and I still haven't covered everything. I 
simply must give credit where credit is 
due, however— without my friend Kirk 
Olynyk's help and tutelage I'd still be 
lighting the wrong pixels without know- 
ing the difference. If you're into this 
kind of discrete math (it's so useful for 
raster graphics) and you want to learn 
more, Concrete M athemati cs (Addison 
Wesley, 1994) by Ronald L. Graham 
and Oren Patashnik is great. 

Also, while discussing my article 
"C hanging the R ules for T ransparent 
Bits" (Under the H ood, Feb. 1995) on 
rec.games.programmer, Rich Gorta- 
towsky (rg@raster.kodak.com) mentioned 
that for best results, your RLE compres- 
sor should try to compress vertically as 
well as horizontally. I totally agree. 

Finally, I promise we'll get back to 
the actual texture mapping portion of 
the texture mapper next time. ■ 

C hris H ecker wants a single- cycle 
integer multiply on future x86 processors so 
bad he can taste it. Yum yum. You can con- 
tact him via e-mail at checker@bix.com or 
through Game Developer magazine. 
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Height , X , ErrorTerm) ; 
X += pVertices [Top] . X + 1; 

FloorDivBod (Width , Height , XStep , Numerator) ; 
Denominator = Height; 

OneOverZ = Gradients. aOneO»erZ[Top] ; 
OneOverZStep = XStep * Gradients. dOneOverZdX 

+ Gradients. dOneOverZdY; 
OneOverZStepExtra = Gradients. dOneOverZdX; 

UOverZ = Gradients. aUOverZ[Top]; 
UOverZStep = XStep * Gradients. dUOverZdX 

+ Gradients. dUOverZdY; 
UO»erZStepExtra = Gradients. dUOverZdX; 

VOnerZ = Gradients. al/OverZ[Top] ; 
VOverZStep = XStep * Gradients. dVO»erZdX 

+ Gradients. dVOverZdY; 
VO»erZStepExtra = Gradients. dVOverZdX; 

} 

} 

/»»****»*** DrawScanLine ************/ 

void DrauScanLinet BITHAPINFO const *pDestInfo, BYTE *pOestBits, 
gradients const ^Gradients, edge *pLeft, edge *pRight, 
BITHAPINFO const *pTextureInfo, BYTE *pTextureBits ) 

{ 

// assume dest and texture are top-down 
assert((pDestInfo->bmiHeader.biHeight < 0) &it 

(pTextureInfo->bmiHeader.biHeight < 0)); 

int DestWidthBytes = (pOestInfo->bmiHeader.bi«idth + 3) Si "3; 

int TextureUidthBytes = (pTextureInfo->bmiHeader.biWidth + 3) & "3; 

int XStart = pLeft->X; 

int Width = pRight->X - XStart; 

pOestBits += pLeft->Y * DestWidthBytes + XStart; 

float QneOverZ = pLeft->OneO»erZ; 
float UOverZ = pLeft->UOverZ; 
float VOverZ = pLeft->VOverZ; 

whilefwidth- > 0) { 
float Z = 1/OneOverZ; 
int U = UOverZ * Z; 
int V = VOverZ * Z; 

*(pDestBits++) = *(pTextureBits + U + (V * TextureUidthBytes)); 

OneOverZ *= Gradients. dOneOverZdX; 
UO»erZ += Gradients. dUQ»erZdX; 
VO»erZ += Gradients. dVO»erZdX; 

} 

} 
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DOUBLE-BUFFERED GRAPHICS 



A C++ Class for C 

Double- 
Graphic 



Platform 
Buffered 



What if someone told you that 
you could release a game 
simultaneously on W in- 
dows, M acintosh, and DOS 
with no more effort than it 
takes you to release a D S 
game now? Of course, you'd 
kick the person off your 
staff, find a loophole in his or her con- 
tract, or refuse the project proposal. 
There are no freebies in software devel- 
opment. 

But what if someone said you could 
release your product on M acintosh and 
W indows with very little extra work and 
showed you how to do it? 

This article takes the first step in 
that direction by defining a simple dou- 
ble-buffering architecture that will lever- 
age your existing three-dimensional ren- 
dering, animation, sprite composition, 
and other custom 8- bit graphics code 
onto W indows and M acintosh systems. 
Using the small C++ class implemented 
here, you will be able to write 32- bit 
graphics applications that compile and 
run without changes on M acintosh Sys- 
tem 6.0.7 and 32-bit Windows (includ- 
ing W in32s and W indows 95). 

Double-Buffered Graphics 

Double-buffered graphics provide the 
core graphics technology that power 
almost all high-performance desktop 
multimedia and entertainment software. 
From simple card games to immersive 
three-dimensional environments, such 
graphics use offscreen memory to hide 
image composition from the user and 
provide smooth transitions between 
frames of animation. Most games 
today— and probably most games created 



in the near future— will rely on copying 
or page- flipping 256- color graphics from 
offscreen memory to display memory. 

Full-screen 8-bit double buffers 
such as these are chunks of RAM man- 
aged in such a way that a one-to-one 
mapping exists between pixels on the 
screen and bytes in the buffer. That's all 
double buffering is, so why not abstract it 
in a platform- independent interface? 

All it takes to create an image in the 
offscreen buffer is a definition of the 
screen-to-offscreen mapping and a 
method to describe the image in the off- 
screen buffer to the screen. For all the 
platforms game developers generally deal 
with, this requires at most four pieces of 
information: 

• pBits, a pointer to the offscreen buffer 
byte that maps to the screen point (0, 
0). 

• Stride, the number of bytes between 
the buffer byte that maps to the screen 
point (x, y) and the buffer byte repre- 
senting (x, y+1). 

• Width, the width in pixels of the rec- 
tangle represented by the offscreen 
buffer. 

• Height, the height in pixels of the rec- 
tangle represented by the offscreen 
buffer. 

G iven these four pieces of informa- 
tion, you can implement any graphics 
algorithm to render three-dimensional 
texture- mapped environments, animate 
complex action sequences, or present tic- 
tac-toe at 30 frames per second. T o make 
those graphics routines work on any plat- 
form, all you need is that magical inter- 
face that provides these four elemental 
pieces of information and a way to dis- 
play completed images on the screen. 
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Listing 1 shows the public aspects 
of this dream interface in a simple C++ 
declaration of a class called coffscreen- 
Buffer. A II operations on the class except 
GetBits are declared const because they 
do not allow change to the buffered 
image or to the size of the buffer. I 've 
added the Lock and Unlock methods, 
which I II explain. 

Before digging into various imple- 
mentations Of COffscreenBuffer, let's take 
a look at how we can use such an inter- 
face. Say I have a pointer called pBuffer 
to a COffscreenBuffer object, and I want 
to set a single pixel to a given color index. 
From the definition of pBits and Stride, I 
can deduce that for any point (x, y) in the 
buffer such that x > and y > and x < 
W idth and y <H eight, the memory loca- 
tion pBits + Stride * y + x holds the 
corresponding byte of offscreen memory. 

Using this definition, I can con- 
struct a SetPixel function using the fol- 
lowing lines of code: 

char unsigned *pPixel = 

pBuffer- >GetBits() 

+ pBuffer->GetStride() * y + x; 
*pPixel = Color; 

Of course, this doesn't include any 
validation or clipping tests, and it's also 
not very useful in the inner loop of an 
optimized rendering engine. But you get 
the idea. 

A nother simple graphics function 
would be to fill the buffer with a solid 
color. Using the four atomic offscreen 
data, I could perform this buffer clear 
with a few simple instructions: 

char unsigned *pBits = 



pBuffer->GetBits(); 
for (int y = 0; 
y < pBuffer->GetHeight(); 
++y, pBits += pBuffer->GetStride()) 
memset(pBits, Color, 
pBuffer->GetWidth()); 

For every line in the buffer, this fills 
as many bytes with the specified color as 
there are horizontal pixels, then skips 
down to the beginning of the next line. If 
I know that the buffer occupies contigu- 
ous memory, that any additional bytes 
included as padding are ignored, and that 
Stride is positive, I can make a small 
optimization and write the buffer clear 
likethis: 

long BufferSize = pBuffer-> 
GetHeightO * pBuffer->GetStride(); 

memset(pBuffer->GetBits() , 
Color, BufferSize); 

This would, however, be a bad idea, 
as stride has been defined as a signed 
long value and will often be negative on 
W indows machines. 

A third simple example would be to 
draw a 45-degree line from the point (x, 
y) to the point (x+n, y+n), where n is 
positive. N o problem: 

char unsigned *pPixel = 
pBuffer->GetBits() + pBuffer-> 
GetStrideO * y + x; 
// Adding Stride+1 moves the 
//pointer from (x,y) to (x+l,y+l) 
for (int i=0; i<n; ++i, pPixel += 
pBuffer->GetStride() + 1) 
*pPixel = Color; 

With some extrapolation on the 
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Double-buffering is 
fhe heart of high- 
performance 
graphics. Wifh this 
C ++ class, you'll be 
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code once and com- 
pile it for Windoius or 
fhe Nacinfosh! 
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Listing 1. Public Functions 



class COffscreenBuffer 
{ 

public: 

// Basic information access 
char unsigned *GetBits(void); 
long GetStride(void) const; 
int GetWidth(void) const; 
int GetHeight(void) const; 

// Displaying the buffer 
void SwapBuffer(void) const; 

// Pixel access control 
void Lock(void) const; 
void Unlock(void) const; 

}; 



part of the reader, these simple examples 
show that the COffscreenBuffer interface 
shown in L isting 1 provides all the essen- 
tial elements for a complete graphics sys- 
tem. Further, none use any code outside 
the accepted ANSI C++, supported by 
any compiler worth its salt. 

I n other words, as long as your tar- 
get platform can transfer an 8- bit packed 
pixel image from memory to the screen 
and supports an A N SI C++ compiler, 
you can write a COffscreenBuffer imple- 
mentation and support the drawing func- 
tions above without changes. 

Making It Macintosh 

So let's get down to the business of 
implementing COffscreenBuffer on the 
two platforms most likely to be the mul- 
timedia systems of the future: Windows 
and the M acintosh. On both, I'll show 
you how to exploit system-supported 
double buffering to do everything you 
ever wanted— or at least start you along 
that path. 

Color 32-bit QuickDraw intro- 
duced a new architecture for offscreen 
drawing support on the M acintosh called 
a G W orld, which became a reliable part 
of the operating system in version 6.0.7. 
T his extension allows the use of Q uick- 
Draw functions to draw into structured 
offscreen memory, and it enables the 
M acintosh version of COffscreenBuffer 
declared in L isting 2 and implemented in 
L isting 3. 

Constructing a buffer from a 
G W orld requires a single call to the 
handy function called NeuGWorld. This 



API requires a rectangle describing the 
dimensions of the desired buffer and a 
color table, both of which the COffscreen- 
Buffer constructor swipes from the active 
window. The dimensions come directly 
off the CGrafPort structure, and the color 
table comes from the associated PixMap. 
For good measure, I've chosen to lock 
down every handle ever used here, 
though you may not always have to do 
so. 

The constructor's task finishes with 
the call to NeuGWorld, at which point the 
calling application becomes the proud 
parent of a COffscreenBuffer object. So 
far, so good. H owever, gaining access to 
the bits of that G W orld proves to be a 
trifle difficult because the operating sys- 
tem has allocated the buffer in moveable 
memory. Enter Lock and Unlock, those 
traditional commands that prevent data 
from moving in a linear address space. 

Before our application can touch the 
bits of the offscreen buffer, the Lock 
method has to guarantee that the bits 
won't move during pixel access. Apple 



((include <QD0ff screen. h> // For GUorld stuff 

class COffscreenBuffer 
{ 

public: 

// Basic information access 
char unsigned *GetBits(void) { return pBits; }; 
long GetStride(void) const { return Stride; }; 
int GetUidth(void) const { return Width; }; 
int GetHeight(void) const { return Height; }; 

// Displaying the buffer 
void SwapBuffer(void) const; 

// Pixel access control 
void Lock(void) const; 
void Unlock(void) const; 

// Constructor and Destructor 
COff screenBuff er(void) ; 
"COffscreenBuffer(void); 

private: 

// Common implementation data 
char unsigned *pBits; 
long Stride; 
int Height; 
int Width; 

// Macintosh implementation data 
GUorldPtr OffscreenGWorld; 
char StoredHMUBode; 

}; 



provides the GetGWorldPixMap and LockPix- 
els functions to handle this, and Get- 
PixBaseAddr provides the magic pBits 
pointer when all the locking is done. 
Apple provides the Stride value in the 
rouBytes field of the PixMap structure, but 
the system tacks on the two high bits to 
make things difficult. A simple mask of 
0x3FFF pulls them off the top. 

In addition to locking the image in 
memory and masking off the high bit of 
the scanline offset, I've heard off and on 
that it's also a good idea to make sure the 
memory management unit is in true 32- 
bit access mode. SuapMUMode handles this, 
storing the current mode for restoration 
by the Unlock method. 

T he Unlock method mirrors the 
locking function, allowing the operating 
system to move the offscreen buffer 
around when the application doesn't 
need it. The aptly named system call 
UniockPixeis handles this task, after 
which I reset the cached pBits value to 
zero to avoid being bitten by an attempt 
to access the bits when the buffer is 



Listing 2. Macintosh Declaration 
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unlocked. 

In debug versions, I also add an 
integer LockCount member variable incre- 
mented by Lock and decremented by 
Unlock, and I assert it is zero when the 
COffscreenBuffer destructor is called. 

The Macintosh requires the 
Lock. . .Unlock pair, and other platforms 
may require it as well. All implementa- 
tions of COffscreenBuffer must include 
both methods, whether they do anything 
or not, and all functions written for COff- 
screenBuffer must operate between a 
Lock. . .Unlock pair to be completely 
portable. This includes the previous 
examples and calls to SuapBuffer. 

SuapBuffer provides the memory-to- 
screen transfer for the application when it 
finishes its graphics processing and wants 
to display the image. SuapBuffer will call 
out to CopyBits to do thejob, copying the 
entire offscreen image into the current 
CGrafPort, using the uisRgn as a mask. 
The operating system will handle all the 
work of clipping to the visible window 
area. 

The COffscreenBuffer destructor is 
the easiest of all to implement on the 
M acintosh. I t's just a call to 
DisposeGWorld, which ditches the G W orld 
for good. 

To use the COffscreenBuffer class 
properly on the M acintosh, be sure to 
turn on the pmExplicit and pmAnimated 

flags of all entries in the palette of the 
target window to ensure that the color 
indices used in the offscreen buffer will 
properly match the colors on the screen, 
yielding highest copying speeds and 
proper color matching. 

Windows 

L ike G Worlds on theM acintosh, WinG 
is the obvious candidate for implement- 
ing a double- buffering architecture for 
W indows. W inG lets us create a buffer, 
access its bits, and copy it to the screen 
quickly. The W indows declaration of 
COffscreenBuffer appears in Listing 4. 
The following implementation appears in 
Listing 5. 

WinG allocates an offscreen buffer 
for us when we use a 
WinGCreateDC/WinGCreateBitmap call pair. 
The buffer memory allocated this way 



Listing 3. Macintosh Implementation 



COffscreenBuffer: :COffscreenBuff er (void) 
{ 

// Use the current GDevice and GrafPort to make a GUorld 

CGrafPtr CurrentPort; 

GOHandle CurrentDevice; 

GetGWorld(!tCurrentPort, KurrentDevice); 

// Get the color table from the current port 

PixBapHandle CurrentPixMap = CurrentPort->portPixMap; 

HLock((Handle)CurrentPixHap); 

CTabHandle ColorTable = (*CurrentPixHap)->pmTable; 

// Create a new GUorld with this information 

NewGUorldWOffscreenGUorld, 8, &CurrentPort->portRect, ColorTable, 

CurrentDevice, noNewDevice) ; 
// Store data that doesn't change 

Uidth = CurrentPort->portRect. right - CurrentPort->portRect.left; 
Height = CurrentPort->portRect. bottom - CurrentPort->portRect.top; 
// Release the current PixHap 
HUnlock((Handle)CurrentPixHap) ; 

} 

COffscreenBuffer: :~COffscreenBuf fer( void) 
{ 

// Free the allocated GUorld 
if (OffscreenGUorld) 

DisposeGUorld(Of f screenGUorld) ; 

} 

void COffscreenBuffer: :Lock(void) const 
{ 

PixBapHandle OffscreenPixHap = GetGUorldPixHap(Off screenGUorld); 

if (OffscreenPixMap) 

{ 

// Lock the PixHap memory and pull some info off the PixHap structure 

LockPixels(Of f screenPixMap) ; 

Stride = (*0ff screenPixMap)->rowBytes & 0x3FFF; 

pBits = (char unsigned *)GetPixBaseAddr(OffscreenPixHap); 

// Hake sure the MMU is in true 32-bit access mode 
StoredHMUHode = true32b; 
SwapHHUMode(fcStoredHHUHode) ; 

} 

} 

void COffscreenBuffer: :Unlock(void) const 
{ 

PixBapHandle OffscreenPixHap = GetGUorldPixHap(Off screenGUorld); 

if (OffscreenPixHap) 

{ 

// Unlock the PixMap memory and reset Stride and pBits 
UnlockPixels(OffscreenPixHap); 
Stride = 0; 
pBits = 0; 

// Restore the previous HHU mode 
SwapHHUMode(iiStoredHHUHode) ; 

} 

} 

void COffscreenBuffer: :SwapBuffer(void) const 
{ 

// Copy all bits from the offscreen GUorld to the active GrafPort 
// Note: The offscreen GUorld should be locked! 
CopyBits(St((GrafPort)OffscreenGUorld)->portBits, 

U (Graf Port)thePort)->portBits , 

M)ffscreenGUorld->portRect, ithePort->portRect, 

srcCopy, thePort->visRgn); 
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will always map to the same address. It 
will never move in memory as far as our 
applications can see, so the unneeded 
extra limbs Lock and Unlock can be com- 
piled out by declaring them as empty 
inline functions. Only the constructor, 
destructor, and swap functions remain. 

WinG supports both top-down 
and bottom- up buffer orientations, as 
discussed in every piece of W inG litera- 
ture to date, so the first step in con- 
structing an offscreen buffer is to deter- 
mine the orientation that will make 
memory- to- screen bits fastest. WinG 
provides this information through the 
WinGRecommendOIBFormat function, called 
by the constructor before creating the 
offscreen buffer. 

nee it has the optimal D evice 
Independent Bitmap (DIB) orientation, 
the constructor fills in the biWidth and 
biHeight fields of the BITMAPINFOHEADER 



Listing 4. Windows Declaration 



((include <wing.h> // For WinG stuff 



class COffscreenBuffer 
{ 

public: 

// Basic information access 
char unsigned *GetBits(void) { return pBits; }; 
long GetStride(void) const { return Stride; }; 
int GetWidth(void) const { return Width; }; 
int GetHeight(void) const { return Height; }; 

// Displaying the buffer 
void SwapBuffer(void) const; 



// Constructor and Destructor 
COff screenBuff er(void) ; 
"COffscreenBuffer(void); 

private: 

// Common implementation data 
char unsigned *pBits; 
long Stride; 
int Height; 
int Width; 

// Windows implementation data 
HDC OffscreenDC; 
HBlfflSP OffscreenBitmap; 
HBITMSP OriginalHonoBitmap; 



structure containing the optimal format, 
preserving the sign of biHeight. A color 
table stolen from the current system 
palette completes the information neces- 
sary to create a WinGBitmap and an accom- 
panying WinGDC, which the COffscreen- 
Buffer constructor does for us. Selecting a 
WinGBitmap into a new WinGDC pops OUt a 
stock monochrome bitmap that the 
destructor will need later, so I store it in 
the COffscreenBuffer object until then. 

The Width and Height of the buffer 
came from the foreground window, and 
WinGRecominendDIBFonnat returns the pBits 
for the buffer. Only the Stride remains, 
and it's easily calculated because we 
know the W inG buffer is actually a stan- 
dard W indows DIB. Every scanline of a 
DIB begins on a 4- byte boundary, and 
since our offscreen buffers are one byte 
per pixel, stride is just the DWORD aligned 
Width: 



// Align to the highest 4-byte boundary 
Stride = (Width + 3) & ("3); 

If WinG recommends a top-down 
DIB, that's all the calculation needed to 
set up the buffer. pBits points to the top 
of the buffer, coinciding with (0,0), and 
Stride indicates a positive step through 
memory. 

For bottom-up DIBs, however, 
things must be switched around. As it 
stands, pBits would point to the last 
scanline in the buffer, and Stride would 
be the offset from (x, y) to (x, y-1). If 
you've used WinG before, you'll know 
that flipping these values around to point 
in the correct direction requires only two 
lines: 

// Point to first scanline (end 

of buffer) 
pBits = pBits + (Height - 1) * Stride; 
// Orient Stride from bottom to top 
Stride = -Stride; 

W ith that, the constructor has fin- 
ished its work, and the calling application 
is the happy owner of a W inG -based off- 
screen buffer, wrapped in a COffscreen- 
Buffer object. Your application can draw 
into this buffer however you choose, call- 
ing SuapBuffer when you're ready to dis- 
play an image. 

T he W indows SuapBuffer imple- 
mentation grabs the Device Context from 
the active window and uses a straightfor- 
ward WinGBitBit call to copy the image 
from the offscreen WinGDC to the topmost 
window on the screen. N othing could be 
easier. 

The call to GetDC returns a virgin 
device context that will not reflect selec- 
tions you may have made to previous 
DCs from the window. It contains no 
palette information. If you have gone 
through the effort to create an identity 
palette for the window (or are using the 
WinG halftone palette), your work will 
be in vain unless you register the W in- 
dow with the cs.owndc style, which pre- 
serves device context settings over 
GetDC. . .ReleaseDC call pairs. 

W hen it comes time to destroy the 
COffscreenBuffer, only three steps need to 
be taken: selection of the original mono- 



// Note that this is supposed to be for Win32, so there are no FUR types. 
// However, it could be adapted easily for 16-bit Windows. 



// Pixel access control - these are no-ops in Windows 
void Lock(void) const {}; 
void Unlock(void) const {}; 
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chrome bitmap back into the WinGDC, 
destruction of the WinGBitmap, and 
destruction of theWinGDC. 

Extending the Buffer Class 

T he COffscreenBuffer class I 've developed 
here provides only the most basic ele- 
ments of a double buffering system, 
barely enough to be useful. M any other 
features could make it a very useful tool 
in cross- platform game development, 
but I have left them out for the sake of 
brevity. 

One important thing missing from 
this COffscreenBuffer class is the explicit 
connection of an offscreen buffer to a 
window. As implemented here, COff- 
screenBuffer uses whatever window hap- 
pens to be active at the time a method is 
invoked. When your application isn't in 
the foreground, this can be a messy 
thing! 

It's easy to store a platform- specific 
window identifier in the COffscreen- 
Buffer structure, and you can hang a 
pointer back to the buffer object on the 
window, too. U nder W in32, try using 
Set/GetWindouLong and GWL.USER to Store 
the pointer. On the Macintosh, 
Set/GetWRefCon performs a nearly identi- 
cal task. 

Of course, attaching a buffer to a 
resizable window means you'll have to do 
something smart when the window 
changes size. M atching the buffer 
dimensions to the new dimensions of the 
window wouldn't be a bad idea.... You'll 
need to look at UpdateGWorid on the M ac- 
intosh, and you'll most likely have to cre- 
ate a new WinGBitmap under W indows. 

M any applications don't want an 
API as clumsy as SuapBuffer. You want 
to optimize your screen accesses by 
writing only the areas that haven't 
changed. A SuapRect method would do 
the trick very nicely. Implement it on 
both platforms, and remember to make 
the rectangle description platform 
independent! 

And what about colors? Both con- 
structors use the current palette to initial- 
ize the offscreen color table, but wouldn't 
it be nice to enable color animation? Just 
be sure to maintain that 1:1 offscreen 
mapping for speed. 



Listing 5. Windows Implementation (Continued on p. 34) 



// This is here to keep it off the stack during the constructor call 
struct { 

BITNAPINFOHEADER Header; 

RGBQUAD ColorTable[256]; 
} Bufferlnfo; 

COffscreenBuffer: :COffscreenBuffer(void) 
{ 

HWND ActiveUindow = GetActiveWindowQ ; 

// Bake the buffer the same size as the acti»e window 
RECT ClientRect; 

GetQientRect(ActiveUindow, iClientRect) ; 
Uidth = ClientRect. right - ClientRect. left; 
Height = ClientRect. bottom - ClientRect. top; 
Stride = (Uidth + 3) 4 ("3) ; 

// Set up the header for an optimal WinGBitmap 

if (UinGRecommendDIBFormat((LPBITMAPINFO)!tBufferInfo) ) 

{ 

// Preserve sign on biHeight for appropriate orientation 
Bufferlnfo. Header. biUidth = Uidth; 
Bufferlnfo. Header. biHeight *= Height; 

// Grab the color entries from the current palette 
HDC hdcScreen = GetDC(ActiveUindow); 
if (hdcScreen) 
{ 

PALETTEENTRY Palette[256] ; 

GetSystemPaletteEntries(hdcScreen, 0, 256, Palette); 
ReleaseDC(ActiveUindow, hdcScreen); 

// Convert the palette entries into RGBQUADs for the color table 

for (int i=0; i<256; ++i) 

{ 

BufferInfo.ColorTable[i].rgbRed = Palette [i] .peRed; 
Bufferlnfo. ColorTable[i].rgbGreen = Palette [i] .peGreen; 
Bufferlnfo. ColorTable[i].rgbBlue = Palette [i] .peBlue; 
Bufferlnfo. ColorTable[i].rgbReser«ed = 0; 

} 

} 

// Create the offscreen DC 
QffscreenDC = UinGCreateDCQ; 
if (OffscreenDC) 
{ 

// Create the offscreen bitmap 
Off screenBitmap = UinGCreateBitmap (Off screenDC, 
(LPBITMAPINFOJ&Bufferlnfo, (void * *)fcpBits); 

if (OffscreenBitmap) 
{ 

// Adjust pBits and Stride for bottom-up DIBs 

if (Bufferlnfo. Header. biHeight > 0) 

{ 

pBits = pBits + (Height - 1) * Stride; 
Stride = -Stride; 

} 

// Prepare the UinGDC/UinGBitmap 
OriginalNonoBitmap = (HBITHAP)SelectObject(Off screenDC, 
OffscreenBitmap) ; 

} 

else 
{ 

// Qean up in case of error 
DeleteDC(0ff screenDC) ; 
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Wrapping it Up 

To compile the code presented in this 
article, I used M icrosoft Visual C++ 2.0 
on Windows NT version 3.5 and Syman- 
tec C ++ 7.0 on M acintosh System 7.0. I 
ran the applications created on W indows 
3.11 with W in32s, W indows N T v. 3.5, 
and M acintosh System 7.0. The graphics 
code implemented on top of the coff- 
screenBuffer API did not change. 

If multiplatform graphics program- 
ming can be this easy, the excuses for 
writing DOS-only games begin to look 
silly. Take, for example, that it took only 
a weekend (with no sleep) to create a 
graphics-only version of D oom for W in- 
dows using W inG because of the struc- 
tured design chosen by the programmers 
at id Software. M ost of the third- party 
three-dimensional rendering systems on 
the market today have at least three ver- 
sions— DOS, Windows, and Macintosh. 
Why shouldn't you? 

The M icrosoft machine has finally 
started cranking up and facing the prob- 
lems of providing real game support in 
W indows, much of it promised for W in- 
dows 95. M ore and more M acintosh 
games are appearing on the market, and 
maybe one day someone will actually 
come up with a decent M acintosh joy- 
stick. DOS continues to score with game 
programmers, but users hate the configu- 
ration problems. 

Using a simple system like the COff- 
screenBuffer class introduced here will 
enable all of your existing graphics rou- 
tines on all three platforms and may help 
you reach more users. W ith the advent of 
W indows 95 and its promised support 
for sound mixing and joystick input, and 
with the multimedia capabilities already 
provided on M ac and W indows, your 
reasons for sticking exclusively to DOS 
begin to look shortsighted. W hy not take 
the cross-platform plunge? ■ 



Listing 5. Windows Implementation (Continued from p. 33) 



OffscreenDC = 0; 



} 



COffscreenBuffer: :~COffscreenBuffer(void) 
{ 

// Delete the offscreen bitmap, selecting back in the original bitmap 

if (OffscreenDC M OffscreenBitmap) 

{ 

SelectObject(Off screenDC, OriginalMonoBitmap) ; 
DeleteObject(Of f screenBitmap) ; 

} 

// Delete the offscreen device context 
if (OffscreenDC) 

DeleteDC(Off screenDC) ; 

} 

void COffscreenBuffer: :SwapBuffer(void) const 
{ 

// Use the DC of the active window 

// NOTE: You'll lose the 1:1 palette mapping if the Uindow isn't CS.OUNDC 
HWND ActiveUindow = GetActiveWindowQ ; 
if (ActiveUindow) 
{ 

HDC ActiveDC = GetDC(ActiveUindow); 

if (ActiveDC) 

{ 

// Perform the bit! 
if (ActiveDC) 
{ 

UinGBitBlt(ActiveDC, 0, 0, Uidth, Height, OffscreenDC, 0, 0); 
ReleaseDC( ActiveUindow, ActiveDC); 

} 

} 

} 



J on B lossom is the coauthor of the 
WinG graphics library for Windows and is 
the author of G ossamer, a free three- di men- 
si onal polygon engine for the M adntosh. H e 
currently works for M axis and can be 
reached at blossom@mobius.net or through 
G ame D eveloper magazi ne. 
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Figure 1. The Three-Dimensional Graphics Pipeline 




► 



Rendering 




Imagine you have just purchased 
the top-of-the-line three-dimen- 
sional game board for your PC. 
You find yourself playing a flight 
simulator with texture- mapped 
polygons and digital sound effects. 
You can hear the roar of the 
engines as you fly over the San 
M ateo bridge. You execute a steep dive, 
and, squeezing down on the shaking 
joystick, you blast away at the terminals 
spreading havoc amongst the innocent. 

You've fed your lust for destruc- 
tion. T hen you hear a voice say that 
M offett Field has just launched inter- 
ceptor F14s to hunt you down. Let the 
missiles fly— you're ready for a dog- 
fight. At this point, you don't really care 
that the hills are texture- mapped poly- 
gons using real Landsat imagery. You 
are much more interested in surviving 
the upcoming dogfight. Unfortunately, 
as you pass over the Oakland hills at 
500 feet, the frame rate goes down, and 
your game turns into a major drag. 
W hat happened? 



Frame Rate Blues 

T he frame rate fell below one frame per 
second because the game accelerator's 
graphics capability was unable to han- 
dle the number of polygons in the 
scene. H ow do you avoid buying a 
graphics card that makes a game 
unplayable? W hat measurements or cri- 
teria can we use to judge the perfor- 
mance of a particular game on a partic- 
ular platform? 

These questions are of concern to 
many game developers as well as play- 
ers. The answer is a standard bench- 
mark that's related to the game rather 
than the hardware pixel memory rates. 
But a standard benchmark implies a 
normalized level of understanding. In 
this article, we'll explore the technology 
associated with measuring game play. 

Three-dimensional graphics are 
the next great graphics hurdle for PCs 
and console platforms. For the past two 
decades, the workstation industry has 
been building three-dimensional graph- 
ics engines for CAD/CAM that range 
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in cost from $20,000 up to millions of 
dollars. Suddenly that technology is 
available in a PC or a game console 
platform. 

W hen a new technology hits the 
streets, the first things we hear are per- 
formance quotes, which are usually 
exaggerations, and downright lies. Open 
up any gaming magazine, and you can 
read about three-dimensional graphics 
performance. For example, a recent arti- 
cle quoted that a certain console box 
could do 1 million flat-shaded polygons 
per second and 500,000 texture- mapped 
polygons per second. W hat do these 
numbers really mean? W hat is flat shad- 
ing, and why is it mentioned? H ow do 
these numbers compare to the 100,000 
polygons per second that a $20,000 
workstation can do? Is it actually true 
that a $300 game console is 10 times 
faster in three-dimensional graphics 
then a $20,000 workstation? Obviously, 
something must be wrong. Let's look at 
the problem by digging a little deeper 
into three-dimensional graphics pro- 
cessing and benchmarks. 

Graphics Processing 

Let's define a three-dimensional scene 
that contains objects from the real world. 
A good example would be a room with 
walls, a floor, table, chair, and TV. Each 
object is broken down into polygons. 
W e've given the polygons position infor- 
mation in terms of width, height, and 
depth, which mathematicians and com- 
puter graphics professionals usually refer 
to asx, y, and z respectively. 

Application software must turn 
each polygon in each of the objects in 
the scene into pixels in the frame buffer 



for visual consumption by an observer. 
This process of converting objects into 
polygons is called tessellation. The 
process of converting polygons into pix- 
els is called the three-dimensional 
graphics pipeline. T he pipeline is com- 
plex and difficult to understand without 
a good understanding of geometry and 
maybe a little physics. M ost of the 
details aren't necessary for this discus- 
sion, but it is necessary to understand 
that these steps exist and they affect the 
overall performance measurements of a 
three-dimensional application. A sim- 
plified version is shown in Figure 1, 
where the arrows show the flow of data 
from one stage to another. The larger 
the arrow, the larger the amount of data 
flow. The greatest amount of data is 
passed from the rasterization step to the 
pixels step. 

Suppose the house in our scene is 
represented by 1,000 polygons. W hen 
these polygons are displayed on a 
1,280- by- 1,024- pixel display, the actual 
number of pixels processed is very likely 
to be in the millions. This implies that 
the majority of the time in the graphics 
pipeline is spent generating pixels— and 
this is true. Over 80% of the time spent 
in the graphics pipeline is spent in the 
rasterization stage generating pixels. To 
accelerate three-dimensional graphics, 
first-generation chip designers are 
accelerating the rendering and rasteri- 
zation steps. This produces the highest 
performance gain for the least amount 
of investment. T he G lint chip from 3D 
Labs is a perfect example of a first-gen- 
eration hardware solution. This chip 
converts triangles from x,y,z points into 
pixels, using a 64-bit memory interface. 



Stephen J ohnson 

Nailing three-dimen- 
sional games Ihal are 
playable is no easy 
lash. It's up to the 
industry to create 
standards and 
benchmarks so 
consumers aren't 
confused by false 
magic number models. 
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Three-Dimensional Pixels 

Pixels are generated for the frame buffer 
by flat shading, Gouraud shading, or 
texture mapping. Flat shading fills a 
polygon with pixels that are all the same 
color. Gouraud shading fills a polygon 
with pixels that are computed using 
color gradients. Texture mapping fills a 
polygon with a two-dimensional bitmap 
like a digital photograph. 

E ach of these methods has its mer- 
its. Flat shading is very fast, but it 
doesn't produce a very good simulation 
of the real world. G ouraud shading pro- 
duces a much better representation of a 
real-world object, and it too is fairly 
fast. M ost three-dimensional graphics 
hardware can produce almost exactly 
the same performance with flat- or 
G ouraud-shaded polygons. Texture 
mapping produces very realistic effects, 
but it is much slower than flat or 
G ouraud shading. 

T he 3D console and D oom use 
texture mapping— in the case of the 
game, the technique makes players feel 
like they are in a real three-dimensional 
environment. Unfortunately, for various 
reasons, texture mapping is slow, and 
poor quality texture mapping produces 
a variety of nasty artifacts unacceptable 
to players. 

So, you can generate a three- 
dimensional pixel using one of these 
techniques or any combination of them. 
Figure 2 shows a three-dimensional 
pixel, which is the depth value and the 
x, y location taken together. T he z value 
is stored into a z buffer. A z buffer is a 
large chunk of memory dedicated to 
saving the last z or depth value for a 
particular x, y location in the display. 
For every pixel in the display, there is a 
z or depth value. For a 1,280- by- 1,024 
display, there exist 1,310,720 pixels in 
the frame buffer and the same number 
of depth values. The biggest problem 
with a z buffer is that it increases the 
amount of memory on the display sub- 
system, and this cost is passed onto the 
consumer by a price increase. 

What's in a Benchmark? 

Traditionally, benchmarks comprised 
small applications that measure the per- 



Figure 2. 3D Pixels Plus Frame Buffer and Z Buffer 
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formance of a machine. D hrystones and 
W hetstones are perfect examples of 
this. These benchmarks contain a vari- 
ety of application-like programs that 
run in a certain period of time on a par- 
ticular platform. 

T he time it takes to execute these 
programs on a particular platform is 
measured and can be compared on a 
relatively fair basis to the time it takes 
to execute them on another platform. 
Usually, the time measured is used to 
compute a standard unit number. The 
industry as a whole looks over the pro- 
grams in the benchmark and decides in 
some sense what is fair and what is not 
fair. 

A similar concept exists in the cur- 
rent PC graphics benchmark area. 
Benchmarks execute a series of graphics 
instructions using a standard applica- 
tion programmer interface (API) like 
the graphics device interface (GDI) in 
W indows. T he time it takes to perform 
the operation is measured. The mea- 
sured time is used to determine how 
many operations the platform can do 
per second. So, numbers like 40 million 
lines per second for a benchmark that 
measures line rendering using GDI are 
reasonable. 

Some benchmarks execute real 
applications in a scripted environment 
resulting in a time measurement. These 
benchmarks often produce a single 



magical number that can be used for 
comparison. 

Benchmarks are not perfect. They 
don't actually measure what a particular 
user is doing on a particular day. 
Instead, benchmarks use a standard 
selection of operations that are sup- 
posed to represent the core activity of 
the average user. Thus, the goal of a 
benchmark is to reduce the potentially 
infinite combination of operations 
(CPU instructions or graphics primi- 
tives) down into a subset that represents 
a reasonable cross- section of application 
or user activities. Presumably, the rep- 
resentation of user activity is fair across 
the variety of platforms available. 

In the workstation arena, the 
three-dimensional benchmark is 
Graphics Performance Criteria (GPC). 
It took 10 years and hundreds of engi- 
neers to implement this benchmark. 
The result is a magic number that you 
can easily translate into frames per sec- 
ond. GPC is essentially an application 
environment with database traversal, 
lighting, clipping, and rendering. On 
PC platforms there exists a large num- 
ber of G PC-style applications— that is, 
games. M ost of the games in the PC 
already output frames per second. A 
perfect example of this is Domark's 
Flight Simulator Toolkit, which lets the 
user display the performance levels 
whilethegameisrunning. 
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Current Benchmarks 

In terms of three-dimensional graphics 
benchmarks, do the 1 million flat-shad- 
ed polygons per second really tell us 
anything about the performance of the 
console box? A number of key factors 
are missing from such a claim, such as 
the database traversal, geometric trans- 
formations, clipping, and lighting. This 
performance claim relates to the final 
stage of the three-dimensional pipeline, 
the rasterization stage. This stage only 
measures the performance of the frame 
buffer memory subsystem. 

Chip designers and developers 
quote the memory subsystem band- 
width in pixels per second, which you 
can easily convert to polygons per sec- 
ond once you know the area of the 
polygon. If the area of the polygon is 
quoted with the polygons per second, at 
least we can better understand the ras- 
terization stage in the pipeline. 

This element is missing from the 
quote of 1 million polygons per second. 
T he performance claims for the console 
box and the workstation mentioned 
previously should be modified to 1 mil- 
lion flat-shaded, single-pixel polygons 
per second vs. 100,000 flat-shaded, 
100- pixel polygons per second. N ow we 
can compare the last portion of the 
pipeline on a relatively fair basis and 
then make a straightforward determina- 
tion that the workstation is 10 times 
faster than the console. 

G iven the area of the polygons, we 
can compare the performance of the 
memory subsystem. A fair comparison 
between two platforms can only be 
made if the other stages have been com- 
puted. Then a frames per second num- 
ber can be computed. 

Game Play Benchmarks 

A unit of measurement for graphics 
rendering must address the application 
level processing that takes place. T his is 
consistent with benchmarks that exist 
for CPUs (D hrystones and W het- 
stones) and for G D I (W inBench). 
Frames per second is a perfectly good 
unit of measurement for game play. 

W ith this type of performance 
metric, it is possible to say one plat- 



form runs Doom II at five frames per 
second, and another runs it at 60 
frames per second. The higher- perfor- 
mance Doom II platform is obvious. 
W ith frames per second, there exists a 
system- level performance measurement 
that is reliable for comparing different 
platforms. 

The performance of rendering one 
scene is computed by taking the various 
boxes shown in Figure 1, measuring the 
performance of each box, and summing 
the results into one aggregate number. 
T he separate numbers are as vital as the 
total result because they give us the 
ability to understand where the bottle- 
necks are and optimize the graphics 
pipeline to achieve higher performance 
for the application. 

U nfortunately, the hardware man- 
ufacturer provides only the polygons- 
per-second statistic, and that isn't 
enough. W e only capture the last stage 
in the three-dimensional application 
pipeline. W hat other information can 
the manufacturer supply that will allow 
us to interpolate a frames- per- second 
statistic? 

Playing the Game 

A fair benchmark and the subsequent 
published results allow the consumer a 
level of confidence. They also allow the 
run-time application to choose an 
appropriate level of complexity in each 
frame at run time. For the actual user, it 
appears that a "magic" number is most 
appropriate, but this number must be 
based on a benchmark that exercises the 
entire graphics pipeline. G ame develop- 
ers must insist that a benchmark can be 
easily translated into a metric like "30 
frames per second at 1,024- by- 768 at 
256 colors per pixel." 

The magic number model can be 
published with the graphics board or 
the actual game platform. These num- 
bers give the consumer some guarantee 
of game play performance. This is the 
same model that is applied to W indows 
performance today. If a graphics board 
or system has a W inBench 95 of 15 
then the consumer knows the platform 
is a good accelerator for the majority of 
W indows applications. Also, if another 



graphics board is a level 19, then there 
is some amount of confidence that the 
later model is faster for most W indows 
applications. 

The magic number also has 
another effect, which isn't necessarily 
seen by the consumer. If the operating 
system environment saves the perfor- 
mance criteria for the platform into 
system information, then the game can 
scale its displayed data appropriately. 
For example, if a certain platform pro- 
duces 10,000 texture- mapped polygons 
per second through the benchmark 
then the application can choose to 
scale back the scene complexity to 
match the platform metrics. You can 
easily accomplish this by storing the 
results of the benchmark in a system 
file and making it accessible to the 
application. M icrosoft has already 
announced its use of this strategy to 
the game developer community. 

This system- wide performance 
information is very important, ascertain 
games show us. For example, T ie Fight- 
er lets the player activate an options 
panel to change the rendering pixel 
complexity at run time. Gouraud shad- 
ing and other effects can be turned on or 
off, depending on the player's choice. 
T he game runs in a default mode that is 
aimed at a 486 DX2/66. W ith system- 
level performance information stored in 
an easily accessible form, Tie Fighter 
can automatically choose the appropri- 
ate level of complexity using the bench- 
mark results for the platform. 

This doesn't remove the necessity 
for the options panel, but it does allow 
the application to start out in a more 
appropriate complexity level. At run- 
time, the game software reads the 
benchmark information and relates it to 
database complexity and rendering per- 
formance, thus determining a "best 
guess" at the frames- per- second number, 
which determines the game play criteri- 
on. T his idea can also be applied to other 
areas of the platform. System- level per- 
formance data can cover CPU, video, 
CD-ROM , audio, fax/modem, and 
other areas to provide the application 
with complete performance information 
about the run- time environment. 
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Conclusion 

It is very difficult today to choose a 
platform that runs the latest and great- 
est three-dimensional game with any 
certainty that the game will be 
playable. This is a problem the PC 
industry must solve. Game developers 
and large companies such as M icrosoft 
are working on a solution. I mentioned 
that the benchmark solution for the PC 
should result in run-time game com- 
plexity adjustment based on a system 
information accessible to the game. In 
addition, the benchmark results for 
platforms and graphics cards should be 
published and understood by users. 

Obviously, the best benchmark for 
a game is the actual game itself, but 
that isn't enough. Some type of stan- 
dard benchmark criteria must exist that 
game developers and players can rely 
on for fair comparison between plat- 
forms. The current performance num- 
bers of polygons per second usually 
only measure the memory subsystem 
performance. It is possible to guess at a 



frame- per- second number from a poly- 
gons- per-second quote if the area in 
pixels is also mentioned. Thus, chip 
vendors must be encouraged to publish 
numbers that are fully qualified, like 
"100,000 lighted, clipped, texture- 
mapped, 50- pixel polygons per frame at 
65,536 colors per pixel on a PPC 604 
processor." W ith this quote, a game 
developer can make an intelligent guess 
as to the resolution and complexity of 
each frame in relation to the game. 

The PC industry should adopt a 
standard benchmark for games and 
applications that use three-dimensional 
graphics. The benchmark should be 
similar to the G PC benchmark used in 
the workstation industry in that it 
should measure the application-level 
performance and not just the memory 
subsystem of the graphics device. If a 
"magic" number is used then it should 
easily translate into scene complexity 
and the various stages of the graphics 
pipeline. This magic number informa- 
tion should be stored with the platform 



in an easily accessible form so that 
games can adjust scene complexity dur- 
ing run time. ■ 



Stephen Johnson has been a computer 
software engineer for the last 15 years. H e 
has extensive background in C, C++, and 
several different assembly languages as 
well as experience with UNIX, M acOS, 
M SD OS, and Windows. About a year 
ago, a game called D OOM popped up on 
his home computer. After one intense 
weekend of blowing away demons, he 
decided to change his career. Strangely 
enough he discovered that writing game 
software is way more fun than 
CAD/CAM drafting packages. H e cur- 
rently resides at D iamond M ultimedia, 
where he is bringing high-resolution, 
hi gh- performance three- di men si on a I 
graphics to every Windows user he can 
find. 
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Table 1. VESA Mode Numbers 
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32K color modes have 1 unused bit, 
and 5 bits of Reg, Green, and Blue data. 
64K color modes have 5 bits of Red 
and Blue data and 6 Bits ofGreen data. 
16M color modes (true color) have 8 
bits each of Red, Green, and Blue 
data. 



Mave you seen some of the 
games that have come out 
recently? A new trend is afoot 
in the game industry. Games 
are moving away from 320- 
by- 200- pixel graphics to 640- 
by-480 and higher resolutions. 
For a long time now, we've 
seen game after game with a screen reso- 
lution of 320- by-200 pixels— first with 
EGA's 16 colors and then VGA's 256 
colors. I n this article I 'II introduce you to 
the force that's making this upward 
graphics mobility in games possible and 
practical: VESA BIOS extensions. 

In the beginning of the PC world, 
IBM would introduce a display adapter, 
and it would automatically become the 
standard to which developers wrote pro- 
grams. First came the CG A in 1982, fol- 
lowed by the EGA in 1985, and the 
M CGA and VGA in 1987. Games and 
other graphics programs adapted to the 
new video standard, compilers added 
built-in support, and the world was an 
orderly place for developers. 

So what happened to produce the 
video card Tower of Babel that we have 
today? IBM brought out the 8514/ A dis- 
play adaptor and users and developers 
gave it a big thumbs down. 

But the maturing PC industry 
didn't sit still for IBM . In the absence of 
a standard that the market was eager for, 
video card manufacturers rushed in to 
provide their own solutions. First came 
enhanced EGA cards with resolutions 
up to 800-by-600 pixels, which were 
quickly swept away by a new wave of 
VGA-compatible cards that took full 
advantage of analog VGA monitors, 
which were rapidly replacing TTL digi- 



tal monitors. M anufacturers rushed to 
outdo each other with 256 colors at 640- 
by-480, then 800- by- 600, and 1,024- by- 
768 pixels. Chip makers added another 
wrinkle when they developed DAC 
chips capable of pumping out 16- bit and 
24-bit color. IBM tried to reassert itself 
with theXGA graphics adaptor, but it 
was too little, too late. 

Lacking an IBM standard to 
mimic, each video card manufacturer was 
on its own when it came to implement- 
ing high- resolution modes. The result 
was a complete lack of consistency 
between video cards in mode numbers, 
extended registers, and drivers. Each 
manufacturer was responsible for devel- 
oping drivers for popular programs and 
providing documentation to software 
developers. And to be honest, software 
developers were pretty low priority for 
most video card makers. 

T he only glimmer of hope for using 
a card's high- resolution modes was pro- 
vided by M icrosoft'sW indows. As W in- 
dows 3.0 and then 3.1 became an indus- 
try juggernaut, it forced manufacturers to 
make W indows video drivers a priority. 
W ith a W indows video driver, any W in- 
dows program could take full advantage 
of the video card's enhanced graphic 
capabilities. The only drawback— W in- 
dows was anything but an ideal choice 
for graphics- intensive games. M icrosoft's 
WinG may bridge that shortfall in the 
future, but up to this point, games have 
pretty much been forced to stick with 
DOS and the VGA standard. 

To alleviate this problem, the Video 
Electronics Standards Association 
(VESA) was founded in 1989 as a non- 
profit organization to set and support 
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industry-wide open standards for the PC 
environment. Starting in August 1989 
with a standard mode number for 800- 
by-600, 16-color SuperVGA graphics, 
VESA has been busy working with the 
PC VESA terms standards for video and 
related items. VESA came up with a sys- 
tem of extensions to the normal VGA 
BIOS that manufacturers could retrofit 
to existing cards. In October 1991, the 
organization released the VESA BIOS 
Extension (VBE) standard, version 1.2. 
To keep up with evolving video cards, 
and the shift to protected mode pro- 
grams, the VBE 2.0 standard was 
released in N ovember 1994. 

W ell, all this history is nice to 
know, but by now you may be asking 
"W hat's in it for me, the game software 
developer?" T he answer is simple: A sin- 
gle, clearcut method for using high-reso- 
lution video modes on most of the video 
cards out there today. The rest of this 
article will give you an overview of what 
VESA BIOS extensions can give your 
software, how they work, and how you 
go about coding them. 

VESA Terms and Features 

For starters, we need to clarify our terms. 
VESA has developed many standards for 
power management, sound, hardware 
and I/O bus interfaces and PC Videos 
BlOSes. This article only covers VESA 
Video BIOS standards known as Video 
BIOS Extensions or VBE for short. 

A video card can provide Video 
BIOS extensions in different ways. The 
ROM BIOS physically on the video card 
can support the V E SA V B E 1.2 or 2.0 
features directly. M ost new video cards 
do this. H owever, due to limited ROM 



space, some new cards don't have a com- 
plete VESA VBE implementation in 
their RO M S. For older cards, the manu- 
facturer can provide a driver that is 
placed in the AUTOEXEC .BAT or 
C N F I G .SY S that augments the card's 
ROM BIOS and provides the VESA 
VBE specific functions that reside in 
RAM . Or a third-party driver, such as 
SciTech Software's U niV BE program, 
can provide the VESA VBE either as a 
TSR or library that can be directly linked 
into a program, providing VESA VBE 
services only while that program is run- 
ning. In many cases, especially with older 
video cards, some RO M BlOSes and 
drivers have bugs or are missing features, 
with hardware panning being the biggest 
culprit. I n these cases, a third party driver 
usually works better than the manufac- 
turer supplied driver or RO M BIOS. 

T he major features that VESA 
VBEs provide are: 

• A consistent way to identify a video 
card, how much memory it has, and 
what video modes and features it is 
capable of. 

• A consistent way to set high resolu- 
tion (SuperVGA) video modes. 

• A consistent way to access all of the 
memory on a video card through a 
"window" of memory, usually at seg- 
ment A 000. 

• A consistent way to save and restore 
SuperVGA M odes. 

• A consistent way to set logical screen 
sizes and page-flip Super VGA 
modes. 

• A consistent way to access video 
DAC registers, including 8-Bit 
DACs and DACs that are not VGA 
compatible. 



Matt Pritc hard 

VESA iiios founded fo 
create industry-wide 
open standards for 
the PC environment. 
Bi| applying these 
standards, develop- 
ers have the benefit 
of a universal method 
for using high-reso- 
lution video modes. 
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The VESA VBE 2.0 standard 
added two major features: 

• Support for fast direct access to 
VESA VBE function from protected- 
mode programs. 

• Support for direct access to all video 
memory in the form of a Linear 
Frame Buffer, accessible from pro- 
tected mode. 

Accessing VESA 
VBE Features 

All VESA VBE functions and features 
are accessed through the INT lOh inter- 
face. For programmers unfamiliar with 
this process, allow me to explain. I n 
addition to traditional hardware inter- 
rupts, the Intel CPU design allows for 
software to issue interrupts. Software 
interrupts are numbered from to 255 
and allow a program to call a function 
without knowing where it is in memory. 
Interrupt number lOh (16 decimal) is 
used to access video BIOS services. 
These services can be in the video card's 
ROM , DOS, or a driver loaded into 
RAM and can be chained together. 

To call a Video BIOS function, the 
function's number is put into the C PU 's 
AX register and any parameters are put 
in the other CPU registers in a manner 
that is function specific. Then the INT 
lOh instruction is executed. The CPU 
transfers control to the interrupt handler 
which processes the selected function 
and returns to the program just as if a 
normal function call had taken place. 

The starting place for any VESA- 
aware program is determining if there 
are VESA BIOS Extensions available to 
program. All VBE function numbers 
have the value 4Fh in the AH register and 
the actual function number in the AL reg- 
ister (The ah and AL registers make up 
the ax register). 

The VBE function to return Super 
VGA information is number 0, and 
before you can call it, you must have a 
buffer into which VESA information 
can be put. T he V B E 2.0 standard 
increased the size of the buffer from 
256 to 512 bytes, but to keep older 
VESA programs from breaking you 
must put the four- character string VBE2 
at the start of the buffer to get the V B E 
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z» ===== — ===== — / 

/* VESACHK.C - Check for VBE Extension and report mode available */ 
/* / 

((include <stdio.h> 
((include <dos.h> 
((include <string.h> 

((define uchar unsigned char 
((define uint unsigned int 

typedef struct { 

/* These items defined in the VESA VBE 1.2 Spec */ 



char Vbe_Signature[4] ; 

int Vbe_Version; 
char far * Oem_String_Ptr ; 
uchar Capabilites[4] ; 

uint far * Video_Mode_Ptr; 
int Total.Memory ; 



/* "VESA" */ 

/* Vesa version * 

/* Name of Video Card */ 

/* Bitmapped features */ 

/* >List of Video Modes */ 

/* Video Bern / 64K */ 



/* These items added in the VESA VBE 2.0 Spec */ 



int 

char far * 

char far * 

char far * 

uchar 
uchar 



Oem_Software_Rev; 
Qem_Vendor_Name_Ptr; 
Dem_Product_Name_Ptr; 
Oem_Product_Rev_Ptr; 

reserved[222]; 
Dem_Data[256]; 



/* From the 1.2 spec */ 
/* VBE 2.0 OEM strings */ 



} VbelnfoBlock; 

int get_VESA_version(VbeInfoBlock far* , int*, int*); 

void main ( void ) 
{ 

VbelnfoBlock VESA.Info; 

int VESA.Version, BajorVer, BinorVer, Mode; 

uint far * Mptr; 

VESA.Version = get_VESA_version(&VESA_Info, iMajorVer, MinorVer); 
if (VESAJersion) { 

printf ("This video card has VBE version 7,d.'/,d extensions. \n", MajorVer, BinorVer) ; 
printf ("The Card Name is "/,Fs'\n", VESA.Info. 0em_String_Ptr); 

/* Display List of Available Modes */ 

printf ("\nThe Following Bodes are supported:\n") ; 
Mptr = VESA.Info. Video_Mode_Ptr; 
while ( (Bode = *Mptr++) != OxFFFF) { 
printf ("mode 7,4. 4xh ".Mode); 

} 

printf ("\n\n"); 
} else { 

printf ("This video card does not have VESA BIOS support\n"); 

} 



int get_VESA_version( VbelnfoBlock far* VESA.Info, int * BajorVer, int * BinorVer ) 
{ 

union REGS in_regs, out.regs; 
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struct SREGS seg.regs; 
int ver, m; 

/* Prepare VESA info Buffer */ 

memsett VESA.Info, 0, 512); 

memcpyt VESA_Info->Vbe_Signature, "VBE2", 4); 

/* Call Int 10, VBE Function (4F)00h */ 

in.regs.x.ax = 0x4F00; 
seg_regs.es = FP_SEG(VESA_Info) ; 
in.regs.x.di = FP_0FF(VESA_Info) ; 

int86x(0xl0, 8iin_regs, 4out_regs, iseg.regs); 

/* Check if VBE Extions present & Get Revision Lei/el */ 

if ( (out.regs.x.ax != 0x004F) 1 1 
(memcmp(VES*_Info->Vbe_Signature, "VESA", 4) != 0) ) 
{ 

return 0; 
} else { 

ver = VESA_Info->Vbe_Version; 
♦MajorVer = (ver » 8); 

/* bug check - Some BlOSes return 0x0102 instead of 0x0120 */ 
/* Check for Binor version in wrong nibble and correct */ 

m = (ver & OxFF); 

if ((ill != ) ti (On k OxOF) != 0)) { 

♦MinorVer = m * 10; 
} else { 

♦MinorVer = (m » 4) * 10; 

} 

return ver; 

> 



2.0 specific additional information. 
After calling the Video BIOS, if the AX 
register has the value 004Fh in it, then 
your BIOS has VESA extensions, oth- 
erwise it doesn't. L isting 1 is a function 
written in Borland C 3.1 that can tell 
you what version of VESA extension 
your card supports, if any, and what 
VESA display modes it has. 

Once you know that your video 
card supports VBE , you still need to find 
out what video modes your card actually 
supports. Two pieces of information in 
the VESA information buffer do this for 
you. The first is the Totaljemory word, 
which returns the amount of actual 
memory on the video card in 64K 
blocks. The second is the 
Video_Mode_Pointer, which is a pointer to 
a list of video modes that the card sup- 
ports. The mode numbers can include 
modes that are unique to your video 



card, numbered from 14h to 7Fh, along 
with mode numbers that VESA has des- 
ignated to be standard on all cards, lOOh 
to llBh. Because of this, it is possible for 
a mode to be listed under two different 
mode numbers, both equally valid. See 
Table 1 for a list of standard VESA 
mode numbers. 

N ow, just because a mode number 
is listed doesn't mean that the mode is 
actually supported (for example, there 
may not be enough video memory). To 
check out the modes you want to use, 

you call VBE function Olh, return Super 
VGA mode information. You must provide 
a 256- byte buffer for information to be 
returned in. If AX comes back with any- 
thing other than 004Fh then the mode is 
not available. If AX is 004Fh and the first 
bit of the first word in the buffer 
(Modejttributes) is 0, then the mode is 
not available. 



The mode information block 
returned by function Olh contains a 
wealth of information about how to 
actually use that mode. T hat information 
includes: 

• W hether the mode is text or graphics, 
monochrome or color. 

• W hether the BIOS text functions are 
available in that mode. 

• The screen resolution and character 
cell sizes. 

• The memory access model and pixel 
layout used by that mode. 

• T he addresses and sizes of the memo- 
ry regions used to read and write data 
in that mode. 

• W hether or not the VGA DAC can 
be used in that mode. 

VESA Memory Addressing 

The whole point of using VESA Video 
BIOS extensions is so that you can write 
a program that doesn't have to know a 
thing about the video card in your sys- 
tem yet can still blast data to the screen 
at full speed. 

M aking a VESA VBE-aware pro- 
gram requires some extra work on the 
part of the programmer, especially in the 
area of graphics memory addressing and 
pixel data organization. To make one or 
more megabytes of video memory acces- 
sible, VESA allows for one or two "win- 
dows" into video memory of up to 64K 
to be mapped into the CPU's address 
space. 

In practice, this usually means a 
64K window at segment A000, but there 
is no guarantee— you need to look. It's 
possible two independent 32K win- 
dows might exist at segments aooo and 
A800. Or you might find two overlap- 
ping 64K windows at segment AOOO — 
one for reading data from one part of 
video memory and another for writing 
data to a different section of video 
memory. 

To access all of video memory VBE 
function {05h, Display Window Control} 

lets you change the position in video 
memory that the window accesses. This 
is also known as "bank switching." One 
thing you can count on varying from 
card to card is the window granularity. 
W indow granularity is the "coarseness" 



GAME DEVELOPER - J UNE/J ULY 1995 45 



GETTING STARTED WITH VESA 



by which the window can be positioned 
in video memory. Some cards can let you 
move the window address around in IK 
increments while others can only move 
32K or 64K at a time. Your drawing 
code will have to take into account that 
some cards may need to switch banks in 
the middle of drawing while others 
won't. For speed considerations, bank 
switching is the only operation that you 
don't need to execute an interrupt to 
access. The VBE can give your program 
the address of a direct function to switch 
banks for the current video mode. 

For protected mode programs, 
VBE version 2.0 opens up a whole new 
set of possibilities. W ith the advent of 
local bus architectures, it became popular 
among video card manufacturers to sup- 
port linear frame buffers. A linear frame 
buffer is where a block of very high 
memory addresses are directly mapped 
into the card's video memory, eliminat- 
ing the need for bank switching entirely. 
Some cards offer both modes of memory 
access, others just one. Developers 
should expect linear frame buffers to 
become the preferred method of video 
memory access in the years ahead. 

Reading and 

Writing Video Memory 

Once you have gotten through VESA 
mode selection and memory addressing, 
actually reading and writing image data 
is anticlimactic. The most common 
memory layout for 256-color modes is 
identical to mode 13h. The only addi- 



s 



E INF 



ciTech Software makes a VESA VBE 2.0 compatible "universal" driver that sup- 
ports over 160 different graphics chips. Its VBE driver is available in TSR form as 
shareware for end users or developers. Linkable library versions are also avail- 
able for software developers. For more information contact SciTech at (916) 894- 
8400 or via e-mail at sales@ scitechsoft.com. 



For more information about VBE contact Kevin Giliett at VESA. The VESA VBE 1.2 and 2.0 
Specs can also be ftp'ed on the internet from x2ftp.oulu.fi. Write to VESA at 2150 N. First 
St., Ste. 440, San j ose, Calif. 95131-2029 or call (408) 435-0333. 



Table 2. VESA VBE Functions (AH = 


4FH) 


AL= 


Function Description VBE Revision 


OOOh 


Return VBE Controller Information 


1.2 


Olh 


Return VBE Mode Information 


1.2 


02h 


SetVBEMode 


1.2 


03h 


Return current VBE Mode 


1.2 


04h 


Save/Restore VBE Mode State 


1.2 


05h 


Display Memory Window Control 


1.2 


06h 


Set/ get Logical Scan Line Length 


1.2 


07h 


Set/Get Display Start 


1.2 


08h 


Set/Get DAC Palette Control 


1.2 


09h 


Set/ Get Palette Data 


2.0 


OAh 


Return VBE 






Protected-Mode Interface 


2.0 









tional need is to use bank switching to 
move the currently needed portion of 
video memory into the access window. 
For high-color and true- color modes, 
you need to do more work. T he size and 
position of each color component can 
vary and your drawing code will need to 
adapt to the different layouts. For exam- 
ple, many new cards use 32- bit pixels for 
24- bit true color modes for higher inter- 
nal performance. Fortunately, the VBE 
mode information block contains 
detailed information on the layout of 
pixels in these modes. L isting 2 demon- 
strates drawing simple patterns using the 
VESA 640-by-480 256-color mode. 

Panning and Page Flipping 

ne of the biggest benefits of VBE s for 
game programs is that it makes possible 
page-flipping and smooth, high-resolu- 
tion animation. VBE functions are pro- 
vided to let the program change the logi- 
cal width of a scan line and select the 
position in video memory from which 
the screen display starts. Just like in 
M ode X, these features 
let programs scroll the 
screen and use double 
and triple animation 
buffering. 

T hese functions 
are simple to use, but 
there are some catches. 
D ifferent video cards 
have different limits on 
how small an adjust- 
ment can be made to 
line widths and screen 
start position. For 
example, a card may 
only allow the start 
position to be on a 



Dword (4-byte) boundary, while another 
might require paragraph (16-byte) 
boundaries. In true color modes, the 
pixel size is usually 3 bytes with no 
unused bytes. So unless the screen start 
position is a multiple of 4 pixels (12 
bytes), the display would start in the 
middle of a pixel, scrambling the color 
data stream! Fortunately, page flipping 
can avoid this easily by starting each 
page on a large boundary such as 4K. 
Smooth panning, on the other hand, 
suffers badly on some cards. 

Palette Functions 

VESA VBEs also provide palette func- 
tions. Two aspects of the palette func- 
tions make them more desirable than the 
traditional method of program the VGA 
card directly. T he first is that the VGA 
Palette registers don't work in super 
VGA modes on some newer cards, while 
using the VBE palette functions does. 
The second benefit is that VESA VBEs 
provide access to 8- bit DACs on cards 
that have them. Normal VGA DAC 
registers only have 6 bits of color data 
per color, but most newer cards can 
process 8 bits of color data per color. 
Using 8-Bit DACs allows for smoother 
looking color ranges and color effects. 

Conclusion 

A well written VESA -aware program 
should have few problems running high 
performance graphics on video cards that 
have yet to be introduced, including the 
increasing number of cards that do not 
have a VGA-compatible core for their 
high-resolution graphic modes. 

If I may share an observation from 
experience, when making a VESA VBE- 
aware program for the first time, you 
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Listing 2. VESADEMO.C (Continued on p. 49) 


i* 


„! 




char Red.Mask.Size; 


/* VESADEMO.C - 1 simple 640x480 VESA Graphics Demo */ 




char Red.Field.Position ; 


1* ===== 


^^ == ^ == ^ ====================== t/ 




char Green.Mask.Size; 








char Green.Field.Position; 


((include <stdio.h> 






char Blue.Mask.Size; 


((include <dos.h> 






char Blue.Field.Position; 


((include <string.h> 




char Rsvd.Mask.Size; 








char Rsvd.Field.Position; 


((define uchar unsigned char 




char Direct.Color.mode.Info; 


((define uint unsigned int 












/* This section available is VBE revision 2.0 & up */ 


/* Stucture to hold VESA VBE Get SVGA Info Results */ 












void far * Physical.Base.Ptr; 


typedef struct { 






void far * Off.Screen.Mem.Offset; 








int Off_Screen.Mem.size; 


/* These items 


defined in the VESA VBE 1.2 Spec */ 












char Reserved[206]; 


char 


Vbe_Signature[4]; /* "VESA" */ 






int 


Vbe_Version; /* Vesa version */ 




} ModelnfoBlock; 


char far * 


Oem_String_Ptr; /* Name of Video Card */ 






uchar 


Capabilites[4] ; /* Bitmapped features */ 




/ ™ U-LODdj. Registers Tor c«U-u n g J-ivi lun ^/ 


uint far * 


Video_Mode_Ptr; /* >List of Video Modes */ 






int 


Total.Memory; /* Video Mem / 64K */ 




union REGS in.regs, out.regs; 








struct SREGS seg regs; 


/* These items 


added in the VESA VBE 2.0 Spec */ 












/* Function Prototypes */ 


int 


Oem_Software_Rev; 






char far * 


Oem_Vendor_Name_Ptr; 




int get_VESA_version(VbeInfoBlock far* , int*, int*); 


char far * 


Oem_Product_Name_Ptr; 




int check_VESA_Mode(int, ModelnfoBlock far* ); 


char far * 


Oem_Product_Rev.Ptr; 




int set.VESA.Mode(int); 


uchar 


reserved[222]; /* From the 1.2 spec */ 




void main ( void ) 


uchar 


0em_Data[256]; /* VBE 2.0 OEM strings */ 




{ 


} VbelnfoBlock; 






VbelnfoBlock VESA.Info; 








ModelnfoBlock MODE.Info; 


/* Stucture to hold VESA VBE Get Mode Info Results */ 












int VESA.Version, MajorVer, MinorVer; 


typedef struct { 














/* Check if VESA Video BIOS Extension installed */ 


/* This section 


available is all VESA revisions */ 












if (! (VESA.Version = get_VESA_version(&VESA.Info, 


uint 


Mode.Attributes; 




iMajorVer, StMinorVer))) { 


uchar 


Win_A_Attributes; /* Memory Window A */ 




printf ("Unabale to run demo.\n"); 


uchar 


Uin_B_Attributes; /* Memory Window B */ 




printf ("This video card does not have VESA BIOS support\n"); 


int 


Uin_Granularity; /* in IK units */ 




return; 


int 


Uin_Size; /* Window Size in K */ 




} 


uint 


Win_A_Segment; /* Segment of Window A */ 






uint 


Win_B_Segment; /* Segment of Window B */ 




/* Check if Mode lOlh is available */ 


void far * 


Uin_Func_Ptr; /* Bank Switch func addr */ 






int 


Bytes_Per_Scan_Line; /* just what it says */ 




if (Icheck.VESA.Mode (0x0101, MODE.Info)) { 








printf ("Odd... This card has VESA BIOS extension but no " 


/* This section 


available is VBE revision 1.2 & up */ 




"support for mode 101h\n"); 








return; 


int 


X.Resolution; 




} 


int 


Y.Resolution; 






char 


X_Char_Size; 




/* Set display to VESA Mode lOlh */ 


char 


Y_Char_Size; 






char 


Number.Of .Planes; 




set_VESA_Mode(0x0101); 


char 


Bits_Per_Pixel; 






char 


Number.Of .Banks; 




/* Draw our Test pattern and wait for a keypress */ 


char 


Memory.Model; 






char 


Bank.Size; 




draw_VESA_triangle_pattern(!iMODE_Inf o,640, 480); 


char 


Number.Of .Image.Pages ; 






char 


Reservedl; 




/* restore text Mode */ 


/* This section 


is used for Memory.Model 0x06 and 0x07 i.e. Direct 




setJESA.Mode (0x03); 


Color and YUV color modes */ 




printf ("this VESA 640x480x256 demo is done.W); 
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{ 



Listing 2. VESADEMO.C (Continued from p. 48) 



return; 

/* Function to get VESA VBE Mode Info for a given mode */ 
checkJESA_Bode(int Bodejum, BodelnfoBlock far* MODE.Info) 

/* First we get info on the desired mode */ 

memsett BODE.Info, 0, 256); /* Clear Mode Info */ 

in.regs.x.ax = 0x4F01; /* Get mode Info Function */ 

in.regs.x.cx = Bode_Num; /* Bode number */ 

seg_regs.es = FP_SEG(VESA_Info); /* Buffer to hold results */ 
in.regs.x.di = FP.OFF(VESA.Info) ; 

int86x(0xl0, Mn.regs, iiout.regs, Siseg.regs); 

if (out.regs.x.ax != 0x004F) { /* Did an Error occur? */ 

return 0; 
} else { 

return Mode.Num; 

} 



"VESA", 4) != 0) ) 

{ 

return 0; 
} else { 

ver = VESA_Info->Vbe_Version; 
♦MajorVer = (ver » 8); 

/* bug check - Some BIQSes return 
0x0102 instead of 0x0120 */ 

/* Check for Minor version in 
wrong nibble and correct */ 

m = (ver k OxFF); 

if ((m != ) kt ((m Si OxOF) != 0)) 
{ 

♦MinorVer = m * 10; 
} else { 

♦MinorVer = (m » 4) * 10; 

} 

return ver; 



int 

{ 



/* Function to perform VESA VBE Bode Set */ 
set_VESA_Bode(int Modejum) 



in.regs.x.ax = 0x4F02; 
in_regs.x.bx = Bode_Num; 



/* Get mode Info Function */ 
/* Bode number */ 



int86x(0xl0, Sdn.regs, iiout.regs, 8iseg_regs); 

if (out.regs.x.ax != 0x004F) { /* Did an Error occur? */ 
printf ("Error attempting to set Mode '/,xh\n", Bode_Num); 
return 0; 

} else { 

return -1; 

} 



} 

int 

{ 



get_VESA_version( VbelnfoBlock far* VESA.Info, 

int * MajorVer, int * MinorVer 



int ver, m; 

/* Prepare VESA info Buffer */ 

memsett VESA.Info, 0, 512); 

memcpyt VESA_Info->Vbe_Signature, "VBE2", 4); 

/* Call Int 10, VBE Function (4F)00h */ 

in.regs.x.ax = 0x4F00; 
seg_regs.es = FP_SEG(VESA_Info) ; 
in.regs.x.di = FP.OFF(VESA.Info) ; 

int86x(0xl0, Sdn.regs, iout.regs, Siseg.regs); 

/* Check if VBE Extions present It Get Revision Level */ 

if ( (out.regs.x.ax != 0x004F) 1 1 
(memcmp(VESA_Info->Vbe_Signature, 



should start by getting the VESA VBE 
1.2 and 2.0 specifications and studying 
them. Then I heartily recommend that 
you obtain other VESA VBE code and 
study it. VBE support varies and the 
specifications leave some room for inter- 
pretation. For example: W here the VBE 
2.0 says "All other registers are pre- 
served," many VBEs still trash the high 
words of extended registers. Another 
example is that some VBEs return a 
value of for a window granularity of 
64K instead of returning 64. 

There is a wealth of information 
and detail involved in using VESA Video 
BIOS Extensions, and we didn't have 
room in one article to cover it all. I do 
hope you now have an idea of what you'll 
be facing when you develop a program 
that uses VESA graphic modes. M aking 
the effort to use VESA VBEs can bring 
great rewards to the developers who want 
their programs to stay on the cutting 
edge. U ntil next time, happy coding! ■ 



M att Pritdwd is presently launching 
his software company Innovatix in Gar- 
land, Texas, and is the author of 
M OD E X 105, a comprehensive freeware 
M odeX library. You can reach him via e- 
mail at matthewp@netcom.com or through 
G ame D eveloper magazine. 
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Wing 



III 



Wayne Sikes 

There ore a lor of 
fighter pilot gomes out 
there these days. 
Woiine Sides novigotes 
through Origin's Wing 
Commander III. the 
third release of the 
Wing Commander 
series, and it mea- 
sures up impressively. 



In this edition of the Chopping 
Block, I review Wing Comman- 
der III by Origin Systems Inc. 
T his technical review contains 
minor spoilers. Wing Comman- 
der III is the third installment in 
the Wing Commander series. 
This version is far more techno- 
logically advanced than previous Wing 
Commander episodes. Game features 
include SVGA digitized movies using 
well-known actors at the game intro 
and end as well as in all cutscenes; the 
graphic engine uses polygon-based, 
texture- mapped VGA and SVGA 
graphics, which result in impressive, 
realistic looking spacecraft; the user 
interface has a clean simple layout and 
is easy to use; and the G eneral MIDI 
soundtrack and digitized sound effects 
add a full layer of realism and excite- 
ment to the game. W ing C ommander 
1 1 1 appears to use a combination of 
rigin's trademarked RealSpace tech- 



nology—which was used in other Ori- 
gin games such as Privateer, Strike 
Commander, and Pacific Strike- 
mixed with advanced polygonal rou- 
tines created specifically for W ing 
Commander III. 

This Is A Big Game! 

The combined English, French, and 
G erman versions of W ing C ommander 
III comes on four C D - R M s. T otal 
distribution size is about 2.3 gigabytes. 
T he W ing C ommander 1 1 1 executable 
(WC3.EXE) plus several primary data 
files are duplicated on each CD-ROM ; 
the unique data files require over 1.8 
gigabytes of CD-ROM storage space. 
The movie files are by far the largest 
files in the game and range in size from 
108M B to 408M B. 

Installing W ing Commander III is 
quite an extensive process. To mini- 
mize data file loading times during 
game play, a full installation is required 
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Listing 1. General TRE File Format 



FILE 
OFFSET 



DATA 
SIZE 



DESCRIPTION 



0-3 char "XTRE" char string. 

4-7 char Blanks. 4 bytes of 00. 

8-11 long Starting Offset of the Indirect Record Pointer Table. 

12-15 long Starting Offset of the Path Name Table. 

16-19 long Starting Offset of the Record Pointer Table. 

20-23 long Offset of the first Data Record in this TRE file. 

24-(xx-l) var Indirect Record Pointer Table. This table contains indirect 

pointers, or "pointers to pointers". The values in this table 
point into the Path Name Table or into the Record Pointer 
Table. 

xx-(yy-l) var Path Name Table. Table of variable-length records containing 

system path names and other path-related data. 

yy-(zz-l) var Record Pointer Table. This table consists of structures 

containing the file offsets and sizes of the Data Records 
in this TRE file. 



zz-EOF 



Individual Data Records. 



NOTES: 

1. var refers to data having variable sizes. 

2. xx is the Starting Offset of the Path Name Table. 

3. yy is the Starting Offset of the Record Pointer Table. 

4. zz is the Offset of the First Data Record. 

5. EOF refers to the end of the file. 



and uses about 40M B of hard disk 
space. A VESA driver is required for 
SVGA graphics. Because Wing Com- 
mander 1 1 1 is such a large game and 
weighs heavily on system resources, it is 
no surprise that many users have had 
trouble installing it. (I experienced 
installation troubles because the size of 
my CD-ROM drivers combined with a 
Pro Audio Spectrum driver exceeded 
the minimum conventional memory 
requirements for my 8M B RAM sys- 
tem. T he game features a boot disk cre- 
ation routine that solved my memory 
management problems.) 

W ing C ommander 1 1 1 requires a 
minimum of 360K conventional RAM 
plus 7.000K of either extended or 
expanded memory. Access to memory 
above 640K is provided by rigin's cus- 
tom JEM M .OVL protected mode 
(DPM I), 32- bit driver. Virtual memory 
is emulated through the use of a swap 
file named SWAPFILE.$$$. The size 
of the swap file is generally determined 
by the amount of free hard disk space, 
and it is usually 15M B to 20M B. The 



swap file is created when W ing Com- 
mander III is booted and erased when 
you exit the game. (This file is erased 
when you exit the game via the Alt-X 
keystrokes. So be sure to erase the swap 
file from your W ing C ommander 1 1 1 
hard drive subdirectory if you exit the 
game using any other method such as 
rebooting your PC.) 

The primary W ing C ommander 
III executable, WC3.EXE, is about 
1.1M B in size. W ing C ommander 1 1 1 
was developed using the M etaW are 
H igh C/C ++ system and is written pri- 
marily in C++. (The M etaW are H igh C 
system features C++ templates and a 
compiler for developing 32- bit protect- 
ed mode applications.) The W C3.EXE 
game engine includes a built-in Exami- 
nation M ode that provides general 
development and debugging informa- 
tion while the game is running. D evel- 
opers can observe the status of the 
numerous game engine flags, accumula- 
tors, stack manipulation calls, and game 
flow data such as act, scene, and mis- 
sion information. I found several 



undocumented keystrokes while explor- 
ing game operation, and I'll summarize 
them further on. 

Data Storage 

E ssentially all of the game data is stored 
in files suffixed with TRE. (I will refer 
to these data files as TRE files.) TRE 
files use a very flexible, open-ended 
data storage format that allows for very 
large files. You can store hundreds of 
megabytesof data in a single T RE file. 

Listing 1 gives a general summary 
of the TRE file format. The first four 
bytes in the file contain the XTRE 
ASCII text string. The XTRE string 
possibly indicates this file contains 
cross-referenced data records. The bytes 
at offsets 8 to 23 contain four pointers. 
T he first three pointers give the file off- 
sets (offsets into the TRE file with the 
first byte in the file referenced as byte 
0) of three data tables. The fourth 
pointer gives the offset of the first D ata 
Record in the file. 

T he first data table in the TRE 
file, the Indirect Record Pointer Table, 
contains pointers (file offset values) that 
reference data in the other TRE file 
data tables. In C nomenclature, the 
Indirect Record Pointer Table contains 
pointers to pointers. T he I ndirect 
Record Pointer Table entries "point" to 
various "pointers" contained in other 
TRE file tables. Each entry in this table 
is an 8-byte structure. The first four 
bytes are bit flags and the last four bytes 
contain the pointer expressed as a 32- 
bit long value. I observed that the Indi- 
rect Record Pointer Tables of several 
TRE files had "blanks" or empty data 
slots. As I mentioned earlier, the TRE 
file format is flexible and expandable, 
and these empty data slots are probably 
part of this expandable format. 

T he Path N ame T able follows the 
Indirect Record Pointer Table. Embed- 
ded in this table are the A SC 1 1 text 
strings of the source paths along with 
binary (possibly file offset) data related 
to each path name. 

The Record Pointer Table follows 
the Path N ame table. The R ecord 
Pointer Table contains the file offsets 
and sizes of the Data Records stored in 
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the T R E file. T he offset and size of 
each Data Record is contained in an 
eight-byte structure. T he first four 
bytes of each structure give the offset of 
the D ata Record as a long value and the 
last four bytes contain the long size. 

The individual Data Records follow 
these tables. T hese D ata R ecords vary in 
size from just a few bytes to several 
thousand bytes and contain the actual 
game data— fonts, palettes, space and 
vehicle graphics, mission data, game 
flow data, artificial intelligence informa- 
tion, and so on. Some of the game data 
is stored in IFF format, which I'll cover 
in the next section. 

Does the T RE file structure seem 
a bit confusing? Although somewhat 
difficult to understand, this file format 
is cleanly organized. Basically, the 
entries in the three data tables at the 
top of a T RE file reference— or point 
to— all the Data Records found in the 
TRE file. In other words, these tables 
tell the game engine where to find the 
desired data. 

As an example, let's trace the path 
the game engine follows to find a look- 



up table containing the file names of 
the W ing C ommander 1 1 1 missions. 
The game engine opens the GAM E- 
FLOW .TRE file and reads down the 
list of entries in the Indirect Record 
Pointer Table until it finds the entry 
corresponding to our mission file name 
look-up table. The engine reads the hex 
values 62 2b 01 3f 84 07 00 00. As the 
Indirect Record Pointer Table entries 
showed us, the 62 2b 01 3f values are 
bit flags and the 84 07 00 00 bytes con- 
tain the long pointer. 

The data beginning at hex offset 
784 (don't forget about the PC 's method 
of storing data in low byte and high 
byte format) references an entry in the 
Record Pointer Table that reads as ae 13 
f4 00 ac 04 00 00. Keeping in mind that 
the Record Pointer Table contains the 
file offset and size of the actual Data 
Record, you'll see the data for the mis- 
sion file names is stored at hex offset 
f413ae and is 4ac (hex) bytes in size. If 
you verify my example by looking in the 
GAM EFLOW.TRE file for the mis- 
sion file names, you will see these 
names (as A SC 1 1 text) listed using Ori- 



gin's I F F file format. This format is 
discussed in the next section. Listing 2 
gives a summary of the W ing Com- 
mander III mission file names that 
we've extracted from the look- up table. 

IFF File Formats 

Origin has used the IFF file format in 
several games including Privateer, 
Strike Commander, and Pacific Strike 
(see "Bandits at 0x1200 H igh!" Chop- 
ping Block, Dec. 1994, for a discussion 
of the IFF files used in Pacific Strike). 
T o summarize the I F F file format, an 
IFF file is composed of one or more 
forms, with each form containing one 
or more records. The following general 
rules are used in IFF file formatting: 

• All forms have a header consisting of 
the "form" text string followed by a 
4-byte number. This number is the 
number of data bytes in the form. 

• All records have a header consisting 
of a record name (that can be up to 
eight bytes of text characters) fol- 
lowed by a 4-byte number. This 
number is the number of data bytes 
in the record. 

• Records can be located both inside 
and outside of a form. 

Mission Ordering 

Refer to L isting 2 and examine the hex 
code that include the mission file name 
look-up table we discussed previously, 
and you will notice that each mission is 
referenced by a unique record name and 
data group. Each mission record name 
is a text number and the data is a text 
file name. For example, mission 0014 is 
Stored in file misnd003. 

The first mission's record name is 
lookoooo (file name misnaOOl) and the last 
mission's record name is 0066 (misnpOOO). 
The missions are generally grouped 
according to the space system in which 
they are located. For example, missions 
0036 (misnlOOl) through 0039 (misnl004) 
occur in the A Icor System. 

Even though the missions have 
record names giving a one-up order, the 
game engine does not play the missions 
in the specified order. The order in 
which the missions are played is deter- 
mined by how well or how poorly the 



Listing 2. The Mission Look- Up Form 


RECORD NAME 


RECORD DATA (MISSION FILE NAMES) 


LOOKOOOO 0001 0002 0003 


misnaOOl 


misna002 misna003 misna004 


0004 0005 0006 0007 


misnbOOl 


misnb002 misnb003 misnb004 


0008 0009 0010 0011 


misncOOl 


misnc002 misnc003 misnc004 


0012 0013 0014 


misndOOl 


misnd002 misnd003 


0015 0016 0017 


misneOOl 


misne002 misne003 


0018 0019 0020 


misnfOOl 


misnf002 misnf003 


0021 0022 0023 


misngOOl 


misng002 misng003 


0024 0025 0026 


misnhOOl 


misnh002 misnh003 


0027 0028 0029 


misniOOl 


misni002 misni003 


0030 0031 0032 


misnjOOl 


misnj002 misnj003 


0033 0034 0035 


misnkOOl 


misnk002 misnk003 


0036 0037 0038 0039 


misnlOOl 


misnl002 misnl003 misnl004 


0040 0041 0042 


misnmOOl 


misnm002 misnm003 


0043 0044 0045 


misnnOOl 


misnn002 misnn003 


0046 0047 0048 


misnpOOl 


misnp002 misnp003 


0049 0050 


misnrOOl 


misn r002 


0051 


misnb2ne 




0052 


misnc2ne 




0053 


misncBbd 




0054 


misndlb 




0055 0056 0057 0058 0059 0060 


tsimOOl 


tsim002 tsim003 tsim004 tsim005 tsim006 


0061 


misnlOld 




0062 0063 0064 0065 


tsim007 


tsim008 tsim009 tsimOlO 


0066 


misnpOOO 
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player is performing. For example, 
assume you, the player, are doing poorly 
and you fail to complete mission 0039 
(misnl004). (M ission 0039 requires that 
you fly down to Alcor V, take out all the 
ground installations, and rescue the sci- 
entist who knows how to make the 
Tembler Bomb.) T his failure sends you 
to the Proxima System to play missions 
0049 (misnrOOl) and 0050 (misnr002) . 
(M ission 0050 is the horrid mission 
where never-ending waves of enemy 
Kilrathi appear; the game never ends 
and you have lost.) 

In a different scenario, if you are 
doing well and complete mission 0039 
successfully, you jump to the Freya Sys- 
tem and begin mission 0040 (misnmOOl). If 
all goes well after a few missions, you 
will be heading to downtown Kilrah 
with the Tembler Bomb during mission 
0048 (misnp003). 

N ote that more than one mission 
file can be played during a mission. For 
example, consider mission 0041 

(misnm002). The misnm002 file is played 
during the initial space combat part of 
the mission. N ext, the misnm02g file 
plays when the player is doing combat 
on the surface of a planet. Lastly, file 
misnm02b plays during space combat at 
the end of the mission. 

Now that I have explained I FF file 
formatting and how the mission file 
names are stored, I have a little home- 
work for you. Try to find the look-up 
table that contains the names of the 
space systems. H int: The space systems 
IFF file data is in the GAM E- 
FLOW.TRE file. What is the record 
data that corresponds to the record 
name lookoooo in the space systems 
look-up table? 

Undocumented Keystrokes 

I found several undocumented key- 
strokes that are not referenced in the 
game's literature. T hese keystrokes only 
appear to be active during the flight 
mode (when you are in the cockpit fly- 
ing a mission). TheAlt-V keystroke 
displays the game version and the file 
name of the current mission. The dis- 
played file name is found in the mission 
file name look-up table previously dis- 



cussed. The Ctrl-F keystroke toggles 
the readout of the current frame rate in 
frames per second. T he C trl- M , C trl-J , 
and Ctrl-K keystrokes select the mouse, 
joystick, or the keyboard, respectively, 
as your primary flight control device. 

Make Your Missions A 
Little Easier (Or Harder) 

W hile playing through the various mis- 
sions and scenarios I quickly decided 
that my computer pilot needed help 
surviving some of the missions. Altering 
the game weapons (guns and missiles) 
seemed to be the best method for 
increasing my pilot's survival time. I 
wrote a utility called WC EASY that 
edits most of the primary gun and mis- 
sile parameters. The WCEASY.ZIP 
routine can be found on CompuServe in 
the Flight Simulation Forum (GO 
FSFORUM ), Space Combat Library. 

If you want to write your own util- 
ities for altering W ing C ommander 1 1 1 
game play, let me warn you that the 
W ing Commander 1 1 1 game engine is 
very sensitive and very inflexible. The 
complexity of this engine is such that 
little allowance is made for altering 
weapons or missions in drastic ways. (I 
wrote an editor for Privateer, PRED- 
IT, a couple of years ago that let you 
add several hundred missiles to your 
vehicle. D o not do this with W ing 
C ommander III!) 

Also some of the mission (and 
possibly other nonmission) data is 
encrypted or somehow abbreviated in 
structure— possibly a new type of IFF 
file format. Unless you study this for- 
mat carefully, I would not advise chang- 
ing it. Any unallowed changes will at 
best cause the game to halt and will 
quite possibly crash your PC. (Don't 
forget to erase the W ing Commander 
1 1 1 swap file on your hard drive if your 
PC crashes.) 

Wing Commander III: 
The Next Generation 

T he first two installments of W ing 
C ommander were impressive to say the 
least. W ing C ommander 1 1 1 is destined 
to be a landmark that other gaming 
companies will try to reach in the fore- 



seeable future. T he beauty of its graphic 
renderings combined with a good, well- 
acted storyline combine to create a clas- 
sic game. I can honestly say that very 
few games hold my attention long 
enough to keep me playing and replay- 
ing scenarios. I found myself constantly 
wanting the current mission to be com- 
pleted just so I could see what was 
going to happen next. T he term "I nter- 
active M ovie" doesn't seem to do justice 
to what O rigin has created in W ing 
Commander III. 

W ing C ommander 1 1 1 exacts a 
high price in terms of system horsepow- 
er. A Pentium is not required, but in 
order to get the most from the game 
you will need one. Testing the flight 
combat sequences using VGA graphics 
on my 486DX 2/50 gave frame rates of 
three-to-six frames per second during 
periods of heavy combat action, and the 
game occasionally hesitated for several 
seconds in order to load the graphics 
and sounds for explosions or new waves 
of enemy vehicles. The loading times 
ranged from 10 seconds during mission 
waypoint sequencing to 70 seconds at 
mission start up. Is a game with longer 
loading times and lower frame rates 
worth playing until I can upgrade to a 
Pentium? If the game is W ing C om- 
mander 1 1 1 , you bet it is! ■ 



Wayne Sikes has been a computer 
hardware and software engineer for the 
last 12 years. H e has an extensive back- 
ground in C, C++, and assembly language 
programming. H e also has several years 
experience as a computer systems intelli- 
gence analyst, where he specialized in deci- 
phering and disassembling computer code 
while working on classified government 
projects. He has written game engines as 
well as numerous computer gaming help 
utilities. You can reach him via e-mail at 
70733.1562@compuserve.com or through 
G ame D eveloper. 
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Descending 
-to the Top 



Alexander 
Antoniades 

What does iF fake to 
start your own studio 
and develop o new 
gome? In 1993. Nott 
Toschlog and Mike 
Hulas learned the 
ropes when they 
formed Parallax 
studios. This is 
their story. 



Embarking on an ambitious 
project such as a commercial 
game can be a taxing experi- 
ence, and it's good to have 
friends to help get you 
through lean times. For two 
programmers who had a 
dream of starting a company 
and writing their own three-dimen- 
sional game, the journey from concept 
to product became a real learning 
experience. 

M att Toschlog first met M ike 
Kulas in 1986 at SubLogic, where they 
were both working on Flight Simulator 
2 for 68000 series processors (Com- 
modore Amiga, Atari ST, and Macin- 
tosh). In 1988, Toschlog left SubLogic 
for L ooking G lass, where he worked 
with N ed L erner on the C ar and D river 
computer game. Kulas joined them in 
1990 creating game tools for Car and 
Driver. W hile they enjoyed working at 
Looking G lass both Toschlog and Kulas 
yearned for something different. 



Startup 

T oschlog and K ulas had each worked on 
a number of games for various compa- 
nies and were interested in working on 
their own creation. Originally, they had 
kicked around the idea of doing an 
indoor flight simulator using shaded 
polygons, similar to the way they'd 
worked on Flight Simulator 2. But after 
working on Ultima Underworld they 
realized that they could use texture 
mapping to make the game more spec- 
tacular. After considering this for a 
while, they finally got together in April 
1993 and wrote the two- page sketch for 
D escent. 

Their next step was to break away 
and form a company. They settled on 
the name Parallax studios and started 
looking for a publisher. ne of the first 
companies they contacted was Apogee. 
Scott M iller, the president of Apogee, 
was excited by their proposal and set 
them up with a contract. Over the next 
nine months Parallax and Apogee 





Descent, the first game developed jointly by Matt Toschlog's and Mike Kulas's Parallax stu- 
dio, takes place in a mine on a distant planet. 
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worked closely in putting Descent 
together. Apogee supplied them with 
money and experience the company had 
gained making three-dimensional share- 
ware games, while Parallax implemented 
any artistic and structural changes that 
Apogee requested. 

W hile the relationship was work- 
able A pogee had to break it off. A pogee 
was in the midst of starting its three- 
dimensional retail project (see "The Sul- 
tans of Shareware Go Retail," By 
Design, Feb./M ar. 1995), and Descent 
was entering a more expensive stage of 
production. Soon Apogee became 
overextended— it simply had too many 
games in the works— and made a clean 
break with Parallax. 

So it came to be that nearly a year 
later, in January 1994, Parallax Software's 
five- person team (Toschlog, Kulas, artist 
Adam Pletcher, programmer John Slagel, 
and level designer Che-Yuan W ang) was 
almost as far from releasing its first game 
as when it started. T hey had serious work 
to do. W orking from the code they had 
finished, they spent the next three weeks 
frantically putting a mock game to show 
prospective investors. T hey sent the mock 
up, with accompanying letters, to 50 
game companies. From the 50 letters, 
they received three replies, which turned 
out to be two more than they needed. 

I nterplay was one of the three 
interested. T he company signed Parallax 
up immediately. Interplay had been 
eager to test the waters of the shareware 
market ever since it had handled the 
M acintosh release of W olfenstein 3D . 
Under the guiding hand of producer 
Rusty Buchert, Parallax added two more 
people to their team and ended up fin- 
ishing Descent eleven months after 
starting with I nterplay. 

Descent 

ne of the aspects that made D escent 
unique was that it combined all six 
degrees of freedom from a flight simula- 
tor with the traditional Doom texture 
mapping. Toschlog, Kulas, and their 
team did this by placing the player in a 
spaceship surrounded by robot adver- 
saries. T his let them create all the moving 
objects using big polygons that could be 



texture mapped and viewed from any 
angle. T he game takes place in a mine on 
a distant planet, so there's no sky to view, 
and all of the remaining objects that 
aren't polygons are either rotated, so 
they're always facing the viewer, or situat- 
ed in areas where they can't be viewed 
from above. 

Early in the development process, 
Parallax toyed with the idea of having 
irregular objects that were flat bitmaps 
rapidly shift to simulate different view- 
points. But having over 70 bitmaps for 
each stage of a movement ended up using 
too much memory, hence the decision to 
stick with simple polygons. 

Even though Descent's game play 
didn't change much from its beginnings 
with Apogee, Toschlog and Kulas 
learned more about project management 
this time around. For example, Toschlog 
observed that in a project of this size 
almost all things need to be done onsite. 
Sometimes they learned this the hard 
way, as when the music files came back 
towards the end of the project too large 
to fit on two disks. A more positive sur- 
prise development was that team mem- 
bers like Adam Pletcher, who was hired 
as an artist, would often make great sug- 
gestions in areas outside of their special- 
ty, such as game design. 

Following the lead of many other 
companies, Parallax used Doom as a 
benchmark of what to include in its 
game. W hile this took off the pressure of 
worrying about things like cut scenes, the 
team balked at including one of Doom's 
most popular features— N etwork play. 
Parallax was reluctant to add networking 
capability because the work required was 
difficult, but the team also knew it was 
important for comparison with D oom, so 
they gave in. I nterestingly, it was not net- 
work bandwidth that instituted the 
eight-player limit in the final version of 
Descent, but the incredible slowdown 
that occurred if more than eight players 
were in the same room during a network 
game. 

ne area where Parallax took a 
definitive Doom approach was making 
D escent a shareware release. This was a 
decision made during the A pogee days 
and Interplay decided to stick with it. 



Despite the fact that Descent was no 
longer being published by Apogee, 
Apogee let Parallax post Descent on its 
highly accessible Software C reations BBS 
for distribution. 

D espite careful planning and pro- 
gramming there were some problems 
with the 1.0 release of D escent. ne bug 
that bit Parallax hard was when robots 
recharged their shields after the player 
died, forcing the player back to the begin- 
ning of the level. T his took a terrible toll 
on level 7 (the last level of the shareware 
version), in which wearing down the 
"boss" robot's shield over the course of 
many players' ships was the strategy. 
"People aren't going to register a game, if 
they can't even finish the shareware lev- 
els," lamented Kulas. 

After fixing the rejuvenated robots 
bug, another aspect of gameplay was 
criticized by Descent players. While 
players could save pilots and return to 
levels they had completed, there was no 
in-level save game feature (as in 
LucasArts's Dark Forces). Convinced 
that this was too popular a feature to 
overlooked, Parallax added an in- level 
save game option to one of its first 
revisions. 

Ascent 

W hat does the future hold for Parallax? 
First will be the C D -Enhanced version of 
Descent, which will be to Descent what 
D oom II is to D oom, that is, more levels 
with a few new features. After that maybe 
D escent II, but definitely D escent for 
M acintosh, for Sega's Saturn, and Sony's 
Playstation. 

W hile the saying around Parallax 
during the making of D escent was T his 
project is our company," in the future 
Parallax will concentrate on two projects 
instead of one. "W e can't compete with 
W ing C ommander III," admits T oschlog, 
but with two small teams of programmers 
Parallax hopes its games will be written 
and designed well enough that it won't 
have to. ■ 

Alexander Antoniades isG ame D evel- 
oper's editor- at- large. Contact him via e- 
mail at sander@mfi.com or through Game 
Developer magazine. 
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The Three Fs of 3D: 
Features, Functionality, 
And ' Fordabil ity 




The incredible can be made to look believable with the wide array of special effects 
available to 3D Studio users. Shown, a scene from The Daedelus Encounter, a Mechadeus 
title. 



Three-dimensional design is hot, 
and you want it, but a high-end 
workstation isn't on your shop- 
ping list just yet. Where does that 
leave you? Well, hardware 
improvements are making the PC 
a more and more viable alterna- 
tive, and PC-based three-dimen- 
sional modeling, rendering, and animation 
software is cropping up everywhere to cap- 
italize on that fact. T hese products all 
promise the moon, and the ads look swell, 
but do they really deliver? A nd how usable 
are they? This time around I'll give you an 
artist's view of three packages representing 
a broad range of features, functionality, 
and price. 



Working in the three-dimensional 
arena is compute- intensive and on the 
PC that can turn into a major time- 
sink, with scene renders dragging on 
interminably while your poor little hard 
drive emits soul- wrenching little- 
engine-that-could sound effects. Fortu- 
nately, faster CPUs and system buses, 
built-in floating-point units, and a new 
generation of graphics accelerator cards 
have greatly speeded the PC 's ability to 
deal with the rigors of working in and 
rendering three dimensions. W hile of 
course you want all the processor speed 
and RAM you can get your little meat 
hooks into, fledgling three-dimensional 
artists on a tight budget can squeak by 
on a 386 with math coprocessor and 
8M B RAM . Useful libraries of ready- 
made objects and textures are generally 
going to be on C D , so it would be a 
good idea for even a minimalist setup to 
includeaCD-ROM drive. 

Autodesk 3D Studio 

Estimates show that 3D Studio now 
accounts for more than half of the PC 
modeling and animation market, which 
makes it a natural standard for compari- 
son. T his magazine ran a more in-depth 
overview of 3D Studio in a previous 
article ("W hat is 3D Studio?" J une, 
1994), but since that time Autodesk has 
come out with Release 4, and its new 
features make a revisit worthwhile. 

3D Studio runs in DOS, which 
may seem something of an anachronism 
these days. W hile the interface might 
initially come across as clunky to W in- 
dows- dependent users, given the pro- 
gram's depth it's probably much more 
usable than if it were icon driven. Five 
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modules make up the working area of 
3D Studio: 

• The 3D Editor, which allows the 
user to create and alter objects and to 
position virtual lights and cameras 

• The 2D Shaper for creating spline 
polygons, which then are used to 
build three-dimensional objects or to 
define complex paths for animations 

• The 3D L ofter, where two-dimen- 
sional polygons are built up into 
objects 

• The M aterials Editor, to create and 
edit surface materials 

• The Keyframer, for animating lights, 
cameras, and action. 

The user moves back and forth 
freely within these modules, which are 
like task- specific workspaces. Release 4 
features a significantly speedier 3D 
Editor, which is where users spend 
much of their time. 

ne great advantage of 3D Studio 
is its support of network rendering. 
Using a single copy of the software you 
can add any number of networked com- 
puters to a queue to participate in ren- 
dering a project, essentially multiplying 
your computer's resources manyfold and 
saving you valuable time. M ultiple files 
can be lined up for unattended network 
rendering while 3D Studio manages the 
workload, assigning tasks to slave 
machines as they become available. 

A 250- page manual is devoted to 
outlining the many new features in 
Release 4. ne highlight is the Camera 
Control and Perspective M atch capabil- 
ity, which aids in camera placement and 
rendering for coordinating your view 
with a scanned photo image. Another is 
a Keyframe Scripting Language that 



uses BA SI C - like commands to build in 
collision detection and elementary 
physics. T here's also a Fast Preview fea- 
ture that allows rendering modes from 
wireframe to Phong-highlighted 
G ouraud shading for full-color previews 
of animations. Perhaps the coolest new 
feature is the addition of Inverse Kine- 
matics. This makes possible hierarchi- 
cally linked object chains— such as 
jointed limbs— that recognize range- of- 
movement constraints. 

W hile it is tempting to describe 
3D Studio as fully featured, its tremen- 
dous flexibility is further enhanced by 
the availability of myriad third-party 
plug-ins: alluring little extras that let 
you, for example, twist, crumple, or 
explode your three-dimensional cre- 
ations or add smoke, snow, or fireworks 
to a scene and much, much more. 
A utodesk encourages developers to 
build around its product and claims that 
new plug-ins are coming at a rate of 
about one a week— there are already 
over 200 available. All of which makes 
for a very richly featured tool, indeed. 
And it can be yours for about $3,000 
(third- party plug- ins, of course, are sold 
separately). 

But what's it like to use? W hile the 
breadth and depth of 3D Studio is a 
spur to the imagination, the sheer scope 
of it is also somewhat daunting. I found 
the five manuals (that's right, five) were 
clearly written and well organized. T hey 
include an excellent book of tutorials 
that's over 500 pages long yet still bare- 
ly scratches the surface. Savvy users also 
recommend Inside 3D Studio from New 
Riders Publishing (Indianapolis, Ind.), 
a hefty book of tips for newcomers and 



David Sieks 

You need to weigh 
mony factors when 
choosing software 
for three-dimension- 
al design. Sure, it's 
great if a tool is hip 



and cool — hut is it 



affordable, usable, 
and versatile? 
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techniques for professionals, loaded 
with hands-on examples. These and a 
lot of patient experimentation will get 
you going, as the interface— while not 
necessarily intuitive— is certainly fairly 
logical once you're grounded. But keep 
those manuals handy. 

N ew users will quickly find that 
complex paths for animating objects 
and cameras can be achieved fairly easi- 
ly. Geometric forms can likewise be 
created, deformed, and combined with 
relative ease to represent an armchair, 
say, or a spacecraft. Even experienced 
users, however, complain of the diffi- 
culty of creating biomorphic forms. 
One workaround is to check out plug- 
ins from Crestline Software (Crestline, 
Calif.), which offer virtual mannequins 
with walk and run motion, facial 
expressions and hand gestures. Crest- 
line's T im W ilson says models of other 
creatures, starting with dinosaurs, are in 
the works. 

Joel Gwynn, applications specialist 
at Cambridge, M ass.- based Designers' 
CADD Company, an Autodesk reseller 
and design shop, finds that most 3D 
Studio purchasers have a specific task in 
mind when they begin. Designer's 
CADD can go onsite and train users 
through that project so the knowledge 
they're gaining is immediately applica- 
ble, which is a great way for a new user 
to get up to speed. Check with your 
Autodesk dealer about the availability 
of training. There are also training sem- 
inars from Autodesk University. If you 
don't have the luxury of a long stretch 
for innocent, childlike exploration and 
experimentation, that may be your best 
bet. 

Caligari trueSpace 

Or maybe you'll want to take a look at 
what Caligari Corp. has to offer. 
"Usable" is the word Caligari prefers in 
reference to its product, trueSpace for 
Windows. Rather than splitting func- 
tions between various modules its so- 
called "natural user interface" consists of 
one large work area. Features are con- 
tained on a single menu bar of icons, 
with additional controls accessible via 
pull-down menus. Objects are manipu- 



lated onscreen in real time. All this is 
geared toward making trueSpace more 
readily understandable on an immedi- 
ate, visual level. 

And it is. Navigation around the 
workspace could not be more straight- 



almost immediately comfortable. W hile 
I'm griping, let me just add my hopes 
that in future releases Caligari pays 
more attention to documentation. 

W hile trueSpace does not support 
networkable functions, many users 
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interface lends i 

do other three-dimensional modelers. Here, a fighter wielding a 'body-ripper' from a game- 
in- progress by Megabyte Industries. 



forward. You can shift your viewpoint 
up, down, and around in relation to the 
scene or to a selected object, or along 
the Cartesian axes. Objects, lights, and 
cameras are all manipulated in the same 
way. You can open smaller, auxiliary 
view windows (and drag them to any 
location on the screen) to display a 
camera's viewpoint or to show an 
almost instantaneous preview of an ani- 
mation or rendered scene. 

I have only one gripe about the 
interface, and it's admittedly a niggling 
one. T he icon buttons are small and the 
icons themselves rather obscure. As 
your mouse pointer encounters each 
icon, a brief description does appear in 
the status bar at the bottom of the 
screen. H owever, that means you have 
to keep looking back and forth from the 
toolbar to the status bar until you 
become familiar enough with the loca- 
tion and function of each button. That 
comes with time, but it's a little frus- 
trating for the novice user, especially 
since so much else about the program is 



speak favorably of its speedy rendering 
time. Robert Riter of M egabyte Indus- 
tries (M oravia, N .Y.) used trueSpace to 
create three-dimensional animations for 
the Dark Force Productions title 
W ormhole and is using it throughout a 
first-person action game of his own cur- 
rently in development. A former 3D 
Studio user, his experience is that ren- 
dering tasks that might have run 
overnight with that program can be 
completed in a fraction of the time with 
trueSpace. 

H e also finds trueSpace a far better 
tool for character creation. Indeed, its 
modeling tools are not only powerful, 
flexible, and easy to use, they're getting 
better— trueSpace for W indows 2.0 was 
in beta test when I wrote this, with 
release expected for the summer of 
1995. I've been working with the beta 
myself for the past week and have been 
impressed with the fluidity of the mod- 
eling process. Deformation tools have 
been improved over version 1.0 so that, 
using the mouse, you can easily push 
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and pull object faces to alter form. C ali- 
gari has also added three-dimensional 
Boolean operations, which means that 
you can sculpt complex shapes as 
though with a chisel, or by fusing three- 
dimensional shapes together like lumps 
of clay. 

Another coup for Caligari is the 
addition of real-time solid rendering. If 
you've used a three-dimensional pro- 
gram before to create anything more 
than a simple geometric form, you 
know how confusing it can get at times 
to work in wireframe. With trueSpace 
2.0, it is possible to work with rendered 
solid forms onscreen in real-time. Two 
Tenderers are included: 3D R , from 
Intel, and Renderware, from Criterion 
(wireframe is still also an option and 
remains most useful for point editing). 
I 've found that 3D R updates the screen 
much more quickly than does Render- 
ware, though the colors tend to get 
lurid. You can expect even better results 
if you're using one of the new graphics 
cards, such as the M atrox Impression, 
with built-in support for these A Pis. 

Some further improvements to 
enhance the program's creation of pho- 
torealistic effects are the addition of 
adjustable depth of field; Adobe Photo- 
shop plug- in support; motion blur; and 
new seamless procedural textures- 
including wood, granite, and marble- 
that allow user- definable settings for 
roughness, scale, and color. trueSpace 
2.0 will retain the $795 SRP and, if it's 
still not out by the time this hits the 
stands, you can buy version 1.0 and get 
a free upgrade from Caligari when the 
new version does come to market. 

Visual Software's 
Visual Reality 

Visual Software (W oodland H ills, 
Calif.) wants to maketh you like unto a 
god. Yea, verily, and for cheap, too. 
Their Visual Reality suite is a virtual 
Swiss Army knife for the aspiring world 
maker on a budget. It doesn't attempt 
to do everything, mind, and it's not 
exactly a quick learn, but what it does it 
does thoroughly— and for under $300. 

Visual Reality consists of five sepa- 
rate but cooperative applications: 



• Renderize Live is the workhorse of 
the group. It serves as the stage 
around which you place objects, 
lights, and cameras and is also where 
you will render final images or ani- 
mations. 

• Visual M odel is where you create 
three-dimensional objects that you 
can then transfer to your scene in 
Renderize L ive. 

• Visual Font makes possible three- 
dimensional text objects with bevel- 
ing and extruding properties. 

• Visual Image is a two-dimensional 
image editor. 

• Visual Catalog organizes projects 
from the preceding modules and 
facilitates the sharing of resources 
within the suite. 

Visual Catalog is a new feature 
with Visual Reality 1.5 and it's a wel- 
come addition that makes it much easi- 
er to carry on a project between the dif- 
ferent applications. Also the handbooks 
for each module, previously available 
separately, have been combined into 
one integrated user's manual. It's well 
written and helpful, filled with pointers 
for optimizing performance as well as 
aesthetic tips. The tutorials are in 
depth, explaining each step of the 



process rather than just providing a 
quick run-through. 

W hat Visual Software invites is the 
creation of virtual worlds, and toward 
this end Visual Reality's set design tools 
are impressive. The Light Designer in 
Renderize Live provides complete con- 
trol over light and shadow: define 
ambient lighting, point lights, spot 
lights, and area lights; specify color, 
intensity, and attenuation, as well as 
position and direction; shadows can be 
enabled or disabled for each light, and 
the intensity and sharpness of the shad- 
ow set by the user. Photorealistic effects 
are enhanced by adjustable distance 
haze/fog levels and colors, and by cam- 
era settings that simulate the look of 
zoom and wide-angle lenses. Cameras 
are also fully animatable (though it is 
important to note that objects are not 
animatable). M aterials editing and 
mapping capabilities are extensive, not 
to mention that the package comes with 
over 1,000 textures, including 200 
seamless textures. Rendering options 
allow for texture, bump, reflection, and 
transparency mapping. 

Visual M odel, the arena for three- 
dimensional object creation, is also 
packed with features including Boolean 




Create your own virtual worlds with Visual Reality or sample one of theirs. The Northern 
Castle Is just one royalty-free three-dimensional environment available to game developers 
In the Simply Scenes series from Visual Software. 
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operations for adding, subtracting, and 
intersecting forms, along with the usual 
editing tools. Unfortunately, I haven't 
found it very easy to make use of all 
these goodies. Its method of defining 
three-dimensional space is not very 
intuitive, so that I'm always having to 
refer to the manual to make sense of the 
process. And the worlds I've created 
with Visual Reality are lonely places, 
given how difficult I've found it to 
attempt organic forms in the modeler. 

Speaking of lonely virtual worlds, 
Visual Software is introducing a com- 
panion series called Simply Scenes that 
consists of fully rendered yet eerily 
uninhabited royalty-free three-dimen- 
sional settings for game developers to 
use. You can take elements of the three- 
dimensional environment and modify, 
move, retexture, or even remove them 
for use elsewhere. The idea is for 
designers to place their own characters 
and objects within these ready-made 
scenes. A hauntingly beautiful fortress, 
T he N orthern C astle, is one of the first. 



There's also a soup-to-nuts assemblage 
of everyday settings such as a dining 
room, a beach, and a country club lock- 
er room. On deck are Western Town, 
the Solar System, and Lunar and Sea 
Colonies. You can wander alone 
through each of these exotic locales for 
a mere $49 per. 

3D For You Too 

W e've looked at three significantly dif- 
ferent programs, each with its own dis- 
tinct advantages and disadvantages. 
And the marketplace is crowded with 
many more than I could profile here 
even if I'd had the chance to use them 
all, which I haven't... yet. 

I f you've been thinking about mak- 
ing the move to three-dimensional 
design, think some more about just 
what it is you hope to find in those 
three dimensions. As these three exam- 
ples show, there's a wide range of 
prices, features, and functionality to 
consider. Asked to choose between 
them, I'm not sure I could. I'd hate to 



give up the depth afforded by 3D Stu- 
dio, I love the natural feel of working in 
trueSpace, and if I was just starting 
with three-dimensional graphics the 
bang- for- the- buck value of Visual Real- 
ity would surely be tempting. Fortu- 
nately, certain file formats are common 
between programs, so if you do have 
access to a variety of three-dimensional 
software you can probably make use of 
the best features of each. 

If you've been using one three- 
dimensional program and you're not 
satisfied with what you've been able to 
do with it, there may be a better choice 
out there for you. It doesn't necessarily 
mean spending more money this time 
around, either. Rather, it's that quest 
for the brush that fits your hand. ■ 



D avid Sieks is a contributing editor 
to Game Developer. Contact him via e- 
mai I at dsieks@arnarb.harvard.edu or 
through G ame D eveloper magazine. 
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